26 Sep
2012
26 Sep
'12
9:48 a.m.
I'd like to bring the current behaviour of the file tabs to discussion, as the
corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on files in the file
browser reorders the tabs, moving the current file's tab to the right of the old
file's tab.
This behaviour is, so I'm told, to make sure that closing the open file will result in
going back to the previous file.
How is it then that changing files by clicking on the tab does not change the order?
To me it seems this behaviour is quite odd, and it's not standard UI (or is there
another app that moves tabs around like this?).
In my mind, tabs also serve the purpose of organising, and people may want to have tabs in
a logical order (e.g. chapters in a LaTeX project). The fact that tabs can be manually
dragged around suggests that this is something the user can set and which should not be
changed by the program.
In order to keep the intended function of returning to the previous file when the current
one is closed, why not simply keep a history list of tabs per window?
Jonas
26 Sep
26 Sep
2:32 p.m.
On 26 Sep 2012, at 4:48, Jonas Zimmermann wrote:
I'd like to bring the current behaviour of the
file tabs to
discussion, as the corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on
files in the file browser reorders the tabs, moving the current file's
tab to the right of the old file's tab.
This behaviour is, so I'm told, to make sure that closing the open
file will result in going back to the previous file.
How is it then that changing files by clicking on the tab does not
change the order?
To me it seems this behaviour is quite odd, and it's not standard UI
(or is there another app that moves tabs around like this?).
I very much agree. The current behavior is annoying to me. Add tabs at
the end. Keep 'em in the order we opened them.
And reconsider the obnoxious file browser selection behavior too. After
dealing with it for almost a year it still bugs me every day.
Gerd
3:42 p.m.
Hi Gerd,
What is the obnoxious file browser selection you mention? I'm quite happy about how
the browser works.
As for the tabs I would vote for adding new opened files to the end as well, though I was
not annoyed yet by the current UI.
Rolf
On Sep 26, 2012, at 4:32 PM, "Gerd Knops" <gerti-textmate(a)bitart.com>
wrote:
On 26 Sep 2012, at 4:48, Jonas Zimmermann wrote:
I'd like to bring the current behaviour of
the file tabs to discussion, as the corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on files in the file
browser reorders the tabs, moving the current file's tab to the right of the old
file's tab.
This behaviour is, so I'm told, to make sure that closing the open file will result
in going back to the previous file.
How is it then that changing files by clicking on the tab does not change the order?
To me it seems this behaviour is quite odd, and it's not standard UI (or is there
another app that moves tabs around like this?).
I very much agree. The current behavior is annoying to me. Add tabs at the end.
Keep 'em in the order we opened them.
And reconsider the obnoxious file browser selection behavior too. After dealing with it
for almost a year it still bugs me every day.
Gerd
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
4:07 p.m.
On 26 Sep 2012, at 10:42, Rolf Langenhuijzen wrote:
Hi Gerd,
What is the obnoxious file browser selection you mention? I'm quite
happy about how the browser works.
The wait it works is perfectly reasonable, if it were a stand-alone file
browser. But I use it mostly as a project navigator. Despite having used
TM2 every day for hours since it came out:
- I still have to remind myself every time to click the icon to open the
file
- I regularly get briefly confused when the file selected in the file
browser isn't the file I am looking at
- I prefer the root in the file browser to remain stationary, so I would
much prefer if ctrl-cmd-R (Current Document) would scroll/unfold as
needed in the current browser
Gave it a shot, can't get used to it, time to change it.
As for the tabs I would vote for adding new opened
files to the end as
well, though I was not annoyed yet by the current UI.
Usually there is a small number of files I am actively working on, and a
lot of files that get opened to review something or make minor related
changes. I'd prefer if my 'core' files would remain at the front of the
tabs. Heck, most of the times the tabs are not useful at all, because
there are so many of them open in more or less random order that the bit
of filename displayed isn't useful at all. I'd rather set aside part of
what is used by the file browser for a list of opened files, and get a
row more in the editor.
I realize that all of these are personal preferences that feed into my
workflow, and others have other requirements. t would be nice to be able
to customize TM2 behavior to each personal preference, rather than to
what Allan deems the right way. While his logic is usually impeccable,
it doesn't necessarily mesh with my personal real-world use.
Gerd
Rolf
On Sep 26, 2012, at 4:32 PM, "Gerd Knops" <gerti-textmate(a)bitart.com>
wrote:
On 26 Sep 2012, at 4:48, Jonas Zimmermann wrote:
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate I'd like to bring the current behaviour of
the file tabs to
discussion, as the corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on
files in the file browser reorders the tabs, moving the current
file's tab to the right of the old file's tab.
This behaviour is, so I'm told, to make sure that closing the open
file will result in going back to the previous file.
How is it then that changing files by clicking on the tab does not
change the order?
To me it seems this behaviour is quite odd, and it's not standard UI
(or is there another app that moves tabs around like this?).
I very much agree. The current behavior is annoying to me. Add tabs
at the end. Keep 'em in the order we opened them.
And reconsider the obnoxious file browser selection behavior too.
After dealing with it for almost a year it still bugs me every day.
Gerd
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate 
4:14 p.m.
- I still have to remind myself every time to click
the icon to open the file
- I regularly get briefly confused when the file selected in the file browser isn't
the file I am looking at
- I prefer the root in the file browser to remain stationary, so I would much prefer if
ctrl-cmd-R (Current Document) would scroll/unfold as needed in the current browser
Gave it a shot, can't get used to it, time to change it.
+1 to these suggestions.
As for the tabs I would vote for adding new
opened files to the end as well, though I was not annoyed yet by the current UI.
Usually there is a small number of files I am actively working on, and a lot of
files that get opened to review something or make minor related changes. I'd prefer if
my 'core' files would remain at the front of the tabs. Heck, most of the times the
tabs are not useful at all, because there are so many of them open in more or less random
order that the bit of filename displayed isn't useful at all. I'd rather set aside
part of what is used by the file browser for a list of opened files, and get a row more in
the editor.
I realize that all of these are personal preferences that feed into my workflow, and
others have other requirements. t would be nice to be able to customize TM2 behavior to
each personal preference, rather than to what Allan deems the right way. While his logic
is usually impeccable, it doesn't necessarily mesh with my personal real-world use.
Gerd
Rolf
On Sep 26, 2012, at 4:32 PM, "Gerd Knops" <gerti-textmate(a)bitart.com>
wrote:
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate On 26 Sep 2012, at 4:48, Jonas Zimmermann wrote:
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate I'd like to bring the current behaviour of
the file tabs to discussion, as the corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on files in the file
browser reorders the tabs, moving the current file's tab to the right of the old
file's tab.
This behaviour is, so I'm told, to make sure that closing the open file will result
in going back to the previous file.
How is it then that changing files by clicking on the tab does not change the order?
To me it seems this behaviour is quite odd, and it's not standard UI (or is there
another app that moves tabs around like this?).
I very much agree. The current behavior is annoying to me. Add tabs at the end.
Keep 'em in the order we opened them.
And reconsider the obnoxious file browser selection behavior too. After dealing with it
for almost a year it still bugs me every day.
Gerd
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate 
4:31 p.m.
On Sep 26, 2012, at 11:14 AM, River Brandon <river(a)unit-e.com> wrote:
+2
Big +1 to this. I shared a UI wireframe a while back with Allan, suggesting some changes
along these lines. I'd love a smarter list of open files -- maybe something
filterable. I could even imagine using something along the lines of iTunes Smart Playlists
(all files of a certain extension, edited in the last 24 hours, with uncommitted changes,
etc.).
I'd also love it if there were a way to show a project name (or just root directory)
in the window title bar, since when I minimize windows (usually projects I'm not
working on), I only get to see the file that's open, which doesn't tell me much.
I agree as well.
- I still have
to remind myself every time to click the icon to open the file
- I regularly get briefly confused when the file selected in the file browser isn't
the file I am looking at
- I prefer the root in the file browser to remain stationary, so I would much prefer if
ctrl-cmd-R (Current Document) would scroll/unfold as needed in the current browser
Gave it a shot, can't get used to it, time to change it.
+1 to these suggestions. As for the tabs I would vote for adding new
opened files to the end as well, though I was not annoyed yet by the current UI.
Usually there is a small number of files I am actively working on, and a lot of
files that get opened to review something or make minor related changes. I'd prefer if
my 'core' files would remain at the front of the tabs. Heck, most of the times the
tabs are not useful at all, because there are so many of them open in more or less random
order that the bit of filename displayed isn't useful at all. I'd rather set aside
part of what is used by the file browser for a list of opened files, and get a row more in
the editor. 
29 Sep
29 Sep
11:44 a.m.
New subject: Project name in window title (was: Tab behaviour)
On Sep 26, 2012, at 6:14 PM, River Brandon <river(a)unit-e.com> wrote:
[…] I'd also love it if there were a way to show a
project name (or just root directory) in the window title bar, since when I minimize
windows (usually projects I'm not working on), I only get to see the file that's
open, which doesn't tell me much.
In your project’s .tm_properties set something like:
projectDirectory = '$CWD'
windowTitle = '$TM_DISPLAYNAME — ${CWD/^.*\///}$windowTitleSCM'
The windowTitleSCM variable is set in the default properties file to include the SCM
branch (if current project use SCM).
27 Sep
27 Sep
8:26 a.m.
On 26.09.2012 17:07, Gerd Knops wrote:
- I still have to remind myself every time to click
the icon to open
the file
- I regularly get briefly confused when the file selected in the file
browser isn't the file I am looking at
- I prefer the root in the file browser to remain stationary, so I
would much prefer if ctrl-cmd-R (Current Document) would
scroll/unfold
as needed in the current browser
Ditto. I'm used to it but the paradigm still hasn't made sense for me,
I guess as I'm constantly flitting between the command line, TM2 &
whatever 5 other apps I'm using the finder is still a big part of my day
to day. Perhaps if all I was doing was flipping between TM & iTerm it
would make more sense but I'm not.
That said, I don't think I could go back to 1.5 - love all the other
good stuff too much, especially the way the SCM works.
Cheers
Alex
4:26 p.m.
- I regularly get briefly confused when the file selected in the file
browser isn't the file I am looking at
- I prefer the root in the file browser to remain stationary, so I
would much prefer if ctrl-cmd-R (Current Document) would scroll/unfold
as needed in the current browser
+1
Elia
—
☁ @elia <http://twitter.com/elia> (twitter) ✎ elia(a)schito.me (gtalk)
☎ (+39) 348/9051393 perlelia(a)gmail.com (FaceTime)
On Thu, Sep 27, 2012 at 10:26 AM, Alex Sullivan <alex(a)zero-design.info>wrote;wrote:
On 26.09.2012 17:07, Gerd Knops wrote:
- I still have to remind myself every time to
click the icon to open the
file
- I regularly get briefly confused when the file selected in the file
browser isn't the file I am looking at
- I prefer the root in the file browser to remain stationary, so I
would much prefer if ctrl-cmd-R (Current Document) would scroll/unfold
as needed in the current browser
Ditto. I'm used to it but the paradigm still hasn't made sense for me, I
guess as I'm constantly flitting between the command line, TM2 & whatever 5
other apps I'm using the finder is still a big part of my day to day.
Perhaps if all I was doing was flipping between TM & iTerm it would make
more sense but I'm not.
That said, I don't think I could go back to 1.5 - love all the other good
stuff too much, especially the way the SCM works.
Cheers
Alex
______________________________**_________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/**listinfo/textmate<http://lists.macromates.…
8:42 p.m.
Hi Gerd,
I agree with the selected file in the browser is not the current one you're looking
at.. :)
Double clicking the icon etc. to open it.. I don't mind that
For the rest I think personal preferences would be ideal, but also a lot of work (to
implement support I mean).
It sometimes is good to just get a new workflow forced in you. On a pc at work I was still
using pre-dreamweaver Homesite as editor ;) then for a new system I just start using
SublimeText.. I still need to find my way, but that's OK. On the Mac I just decided to
use TM2 and don't even look back (even though TM2 seems slower when I have many files
open, I just can't go back anymore).
But, I saw a lot of +1 replies on your suggestions, so who knows… :)
Cheers,
Rolf
On Sep 26, 2012, at 6:07 PM, Gerd Knops <gerti-textmate(a)bitart.com> wrote:
On 26 Sep 2012, at 10:42, Rolf Langenhuijzen wrote:
Hi Gerd,
What is the obnoxious file browser selection you mention? I'm quite happy about how
the browser works.
The wait it works is perfectly reasonable, if it were a stand-alone file browser.
But I use it mostly as a project navigator. Despite having used TM2 every day for hours
since it came out:
- I still have to remind myself every time to click the icon to open the file
- I regularly get briefly confused when the file selected in the file browser isn't
the file I am looking at
- I prefer the root in the file browser to remain stationary, so I would much prefer if
ctrl-cmd-R (Current Document) would scroll/unfold as needed in the current browser
Gave it a shot, can't get used to it, time to change it.
As for the tabs I would vote for adding new
opened files to the end as well, though I was not annoyed yet by the current UI.
Usually there is a small number of files I am actively working on, and a lot of
files that get opened to review something or make minor related changes. I'd prefer if
my 'core' files would remain at the front of the tabs. Heck, most of the times the
tabs are not useful at all, because there are so many of them open in more or less random
order that the bit of filename displayed isn't useful at all. I'd rather set aside
part of what is used by the file browser for a list of opened files, and get a row more in
the editor.
I realize that all of these are personal preferences that feed into my workflow, and
others have other requirements. t would be nice to be able to customize TM2 behavior to
each personal preference, rather than to what Allan deems the right way. While his logic
is usually impeccable, it doesn't necessarily mesh with my personal real-world use.
Gerd
Rolf
On Sep 26, 2012, at 4:32 PM, "Gerd Knops" <gerti-textmate(a)bitart.com>
wrote:
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate On 26 Sep 2012, at 4:48, Jonas Zimmermann wrote:
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate I'd like to bring the current behaviour of
the file tabs to discussion, as the corresponding issue on github has been closed.
My problem is that switching between files with cmd-T or clicking on files in the file
browser reorders the tabs, moving the current file's tab to the right of the old
file's tab.
This behaviour is, so I'm told, to make sure that closing the open file will result
in going back to the previous file.
How is it then that changing files by clicking on the tab does not change the order?
To me it seems this behaviour is quite odd, and it's not standard UI (or is there
another app that moves tabs around like this?).
I very much agree. The current behavior is annoying to me. Add tabs at the end.
Keep 'em in the order we opened them.
And reconsider the obnoxious file browser selection behavior too. After dealing with it
for almost a year it still bugs me every day.
Gerd
_______________________________________________
textmate mailing list
textmate(a)lists.macromates.com
http://lists.macromates.com/listinfo/textmate
3125
days inactive
3128
days old
9 comments
8 participants
participants (8)
-
Alex Sullivan -
Allan Odgaard -
Elia Schito -
Gerd Knops -
Jonas Zimmermann -
River Brandon -
Rolf Langenhuijzen -
Tim Underwood