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
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
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@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@lists.macromates.com http://lists.macromates.com/listinfo/textmate
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@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@lists.macromates.com http://lists.macromates.com/listinfo/textmate
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
- 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.
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.
River
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@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@lists.macromates.com http://lists.macromates.com/listinfo/textmate
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 Sep 26, 2012, at 11:14 AM, River Brandon river@unit-e.com 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
Gave it a shot, can't get used to it, time to change it.
+1 to these suggestions.
+2
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.
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.
On Sep 26, 2012, at 6:14 PM, River Brandon river@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).
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
- 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@schito.me (gtalk) ☎ (+39) 348/9051393 perlelia@gmail.com (FaceTime)
On Thu, Sep 27, 2012 at 10:26 AM, Alex Sullivan alex@zero-design.infowrote:
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@lists.macromates.com http://lists.macromates.com/**listinfo/textmatehttp://lists.macromates.com/listinfo/textmate
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@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@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@lists.macromates.com http://lists.macromates.com/listinfo/textmate
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
-
Alex Sullivan -
Allan Odgaard -
Elia Schito -
Gerd Knops -
Jonas Zimmermann -
River Brandon -
Rolf Langenhuijzen -
Tim Underwood