Re: Tabs

[Zach LeBar]

Hmmm. All of that was very interesting. Never really gave that much thought to whether or not a more useful metaphor than tabs could be used in Kod. 

Currently Espresso is my main editor, so I'm quite familiar with their approach to this. I'm not a fan of the fact that if I have one window open I have tab capabilities but if I open a "project" I'm given a completely new paradigm: this vertical list. Like was said in the chat transcript, it flies in the face of minimalism, which is what Kod is all about. 

To be honest though, I think all of this is a bit of a straw man argument. If you have too many tabs open, then close some tabs. You're probably working on a project and have the sidebar open with it's directory, so closing and reopening a file is trivial. 

Kod is supposed to be an efficient, elegant, and minimalist text editor. Like was said in the chat, this approach emphasizes that philosophy to the user. 

- Zach LeBar

On Dec 28, 2010, at 11:25 PM, aristidesfl <arist...@gmail.com> wrote:

3:58:55 AM aristidesfl: rsms: I've been thinking about tabs lately

3:59:13 AM aristidesfl: I think you did an awsome job with the chrome tabs

3:59:52 AM aristidesfl: and I think they are the most beutiful and functional tabs I ve seen so far

3:59:54 AM aristidesfl: but

4:00:12 AM aristidesfl: I'm wondering if they are the best solution

4:00:15 AM aristidesfl: I mean

4:00:36 AM aristidesfl: They are pretty intuitive and they are pretty much the standard

4:00:55 AM aristidesfl: and they work pretty well 

4:01:08 AM aristidesfl: (with a few files)

4:01:25 AM aristidesfl: but when we pass the 7 barrier

4:01:45 AM aristidesfl: they start to show their limitation

4:01:51 AM codykrieger: I rather like them, they're wonderful. Already loads better than TM's tabs...we just need a way to have them scroll.

jedivulcan_ [~jedivulca@wikia/majorthomme] entered the room. (4:01:56 AM)

4:02:58 AM codykrieger: Instead of the BS way TextMate does it with the little arrows, and no way to see what actual tabs you have open. Tab scrolling would be awesome.

mikemeyer left the room (quit: Quit: Computer has gone to sleep.). (4:03:09 AM)

4:03:27 AM aristidesfl: codykrieger: 

4:03:45 AM aristidesfl: look at the user list of this chat room

4:04:05 AM aristidesfl: imagine that it what displayed horizontally  

4:04:28 AM aristidesfl: it would take much more time to scan

jedivulcan left the room (quit: Ping timeout: 260 seconds). (4:04:41 AM)

jedivulcan_ is now known as jedivulcan (4:04:42 AM)

4:04:53 AM codykrieger: True, but I don't honestly think that you can ever be truly working with that many files at once. Not efficiently.

4:04:58 AM aristidesfl: because they are spread in a bigger area

4:05:31 AM aristidesfl: codykrieger: not with tabs

4:05:45 AM aristidesfl: codykrieger: not with tabs, you don't

4:05:58 AM codykrieger: I've definitely had that many things open before, but I've never actually worked on that many things simultaneously.

4:06:13 AM puls: has the way textmate or safari does it ever become a serious limitation? I say no

4:06:42 AM codykrieger: Right, I think that it forces you to be more reasonable, actually.

4:07:10 AM aristidesfl: the second reason the vertical disposition works better is because you can scan the initials of the names more easily  

4:07:39 AM aristidesfl: right now

4:07:58 AM aristidesfl: you have to close and open and close and open and close and open

4:08:02 AM aristidesfl: often the same file

4:08:10 AM aristidesfl: because you don't have space

4:08:20 AM aristidesfl: and because it because unmanagable

4:08:23 AM aristidesfl: it's a limitation

4:08:25 AM aristidesfl: not a feature

4:08:27 AM aristidesfl: and

4:08:46 AM aristidesfl: it there are kinds of applications/projects where a few files are ok

4:08:58 AM aristidesfl: others are just to big and complex

4:09:31 AM codykrieger: Limitation can be one of the best parts of a piece of software with a vested interest in minimalism.

4:09:45 AM codykrieger: Limitation within reason, at least.

4:09:47 AM aristidesfl: can

4:09:53 AM aristidesfl: can be

4:10:29 AM aristidesfl: but that is a choice that you want to make yourself

4:10:50 AM aristidesfl: not because is to hard to handle many files

4:11:06 AM aristidesfl: Tabs have limitations

4:11:16 AM aristidesfl: firefox guys are the firt to admit it

4:11:27 AM aristidesfl: and they are currently searching for solutions

4:12:02 AM aristidesfl: I think we should at least give it a thought

4:12:14 AM codykrieger: Giving users less ways to shoot themselves in the feet is a good thing, though. I'd argue that since you can only have so many tabs open at once, without going to multiple windows, it forces you to work on less things at once. Multitasking is a killer of productivity in a lot of cases.

jgjay left the room (quit: Ping timeout: 276 seconds). (4:12:34 AM)

4:12:50 AM codykrieger: Yeah I'm not opposed to checking it out, but tabs seem like a great solution in this case.

4:13:01 AM aristidesfl: multitasking is having to think about managing tabs and coding at the same time

4:13:26 AM aristidesfl: that is multitaskin

4:14:10 AM codykrieger: Maybe. But what would happen to the sidebar? Would it become a dual-functionality kind of thing? Project navigator and open file navigator?

4:14:11 AM aristidesfl: the oposite would be don't care about closing the funcking tabs because you can actually manage them efficiently

4:14:31 AM aristidesfl: that is espresso aproach

4:14:37 AM codykrieger: Espresso has an interesting way of handling it.

4:14:41 AM codykrieger: Exactly, yeah.

4:14:59 AM aristidesfl: I found it weard at begging 

4:15:08 AM aristidesfl: but now find it interesting actually

4:15:26 AM codykrieger: But then how do you navigate those files with the keyboard? cmd+[ and cmd+] aren't as intuitive, because you're not navigating left and right anymore.

4:15:40 AM codykrieger: Or shift+cmd+[ rather.

4:15:47 AM aristidesfl: even more if I could have the files organized by last use, like application swithcer in MacOS

4:17:21 AM aristidesfl: well, we could navigate by typing the name

4:17:31 AM aristidesfl: on the locationbar

4:17:41 AM aristidesfl: or by up and down arrows

4:17:45 AM aristidesfl: or any other shortcut

4:17:47 AM codykrieger: Why not just eliminate open file navigation completely at that point then?

4:17:56 AM codykrieger: And just use an open-quickly model?

4:18:10 AM aristidesfl: that is interesting also

4:18:27 AM aristidesfl: http://www.cs.brown.edu/people/acb/codebubbles_site.htm

4:18:29 AM codykrieger: That's more Vim-like in that it's closer to a modal interface.

4:18:32 AM aristidesfl: did you see this?

dyer_ left the room (quit: Quit: Away). (4:18:55 AM)

4:19:37 AM codykrieger: That is weeeeeeeiiiiirrrddd...

4:20:03 AM codykrieger: Interesting concept. That would really take some getting used to.

4:20:45 AM codykrieger: Considering Kod is supposed to be a text editor, I don't think we can get quite that crazy, but interesting nonetheless.

dyer_ [~dyer@unaffiliated/voxeojohn] entered the room. (4:21:24 AM)

4:21:53 AM alisdair: tabs are pretty silly really

4:22:05 AM alisdair: just load all the files in the project into memory

4:22:14 AM alisdair: and you can switch between them instantly anyways

4:22:54 AM codykrieger: That could be a potentially crippling thing, though. Where do you draw the line with which files to load into memory? Maybe I've got a 90mb log file in the project...don't want that loaded.

4:23:17 AM aristidesfl: yeah that's probably not the best idea ever

4:23:25 AM codykrieger: You could have some kind of filter, I suppose, like "don't load .log files into memory"

4:23:30 AM alisdair: 90mb is tiny though

4:23:32 AM alisdair: on modern systems

4:23:56 AM alisdair: i can have a video project open that's 1.5 gb

4:23:59 AM alisdair: with no problem

4:24:10 AM alisdair: i can't have a couple hundred mbs of text?

4:24:39 AM codykrieger: Yeah, but I think the second Kod starts taking up large amounts of memory upon starting up, it becomes more like a typical IDE in terms of memory usage.

4:25:22 AM aristidesfl: alisdair: but is not only about loading the text

4:25:29 AM aristidesfl: its about parsing

4:25:55 AM alisdair: well

4:25:57 AM aristidesfl: I'm sure your video software doesn't open in a couple of seconds

4:25:59 AM alisdair: you wouldn't preload everything

4:26:03 AM codykrieger: It wouldn't necessarily have to be parsed after being loaded into memory. That would be hugely inefficient on the part of the parser, which should really only parse visible text at once.

4:26:04 AM alisdair: you'd load lazily, on demand

4:26:07 AM alisdair: and parse on demand

4:26:27 AM alisdair: but tabs are just a poor way of organizing trees of data, like projects

4:26:31 AM aristidesfl: but then no advantage in loading into memory

4:26:48 AM aristidesfl: is just tiny text is loads fast anyway

4:26:54 AM aristidesfl: what takes time is parsing

4:27:04 AM aristidesfl: the real purpose of tabs is to provide quick access list of current working files

4:27:19 AM aristidesfl: right now

4:27:41 AM alisdair: right, what i really mean is that when you switch documents, don't discard the current doc, just load the new one

4:27:45 AM aristidesfl: and for that purpose I think espresso approach works better

4:28:01 AM alisdair: every file in the project should be considered a current working file

4:28:34 AM alisdair: if your source hierarchy is insufficient to provide quick access to files, then there's better ways to improve access than tabs

4:28:49 AM aristidesfl: alisdair: sure but a file that you used recently has higher probability of being needed again in the near future

4:29:08 AM alisdair: right, that's why you don't discard it, just keep it referenced but inactive

4:29:34 AM aristidesfl: sure but that implementation details

4:29:40 AM alisdair: the only reason we put up with tabs for quick access to documents is because firefox does it

4:29:48 AM alisdair: and no one has really thought about better ways to do it

4:29:50 AM aristidesfl: I was refering in the user point of view

4:29:59 AM aristidesfl: yes

4:30:02 AM alisdair: i am too, i think tabs are awful

4:30:13 AM alisdair: from a ui perspective

4:30:28 AM aristidesfl: and because tabs are a good real world metaphor

4:30:46 AM aristidesfl: they are not always aweful

4:31:11 AM alisdair: why don't we use a tabbed interface on the desktop then?

4:31:13 AM aristidesfl: but they become when the number of tabs exceeds a certain value

4:31:18 AM alisdair: why a window paradigm?

4:32:44 AM aristidesfl: http://☁.ws/崧

4:32:48 AM aristidesfl: look at this

4:33:22 AM aristidesfl: what I wouldn't give for vertical tabs 

4:33:40 AM codykrieger: Vertical tabs, or an Espresso-like implementation?

4:34:03 AM aristidesfl: I like espresso implementation

4:34:34 AM aristidesfl: cause it just takes a little bit of space from the tree

4:34:59 AM codykrieger: As soon as you have that many things open, though, the whole tree is either gone, or you have to scroll a lot.

4:35:07 AM codykrieger: Both implementations have issues with having large amounts of files open.

4:35:14 AM aristidesfl: sure

4:35:37 AM aristidesfl: but espresso handles more

4:36:01 AM codykrieger: Depends on your window dimensions 

4:38:13 AM aristidesfl: What if

4:38:18 AM aristidesfl: single files

4:38:29 AM aristidesfl: files open in tabs

4:38:40 AM aristidesfl: folders open in tabs

4:39:11 AM aristidesfl: if you open files from the tree

4:39:11 AM alisdair: what about instead of persistent tabs, you just keep the last n documents viewed in some sort of queue you can move around in?

4:39:27 AM aristidesfl: yeah

4:39:42 AM aristidesfl: we coud stiil keep tabs

4:39:58 AM codykrieger: Or maybe ditch tabs...Exposé approach.

brettgoulder left the room (quit: Ping timeout: 240 seconds). (4:40:03 AM)

4:40:36 AM codykrieger: Hit a key combo, bam, you're zoomed out and see a bunch of files you've opened with little previews and whatnot.

4:40:49 AM alisdair: yeah

4:40:55 AM alisdair: i think expose is much better than tabs

4:41:05 AM aristidesfl: well..

4:41:07 AM codykrieger: Move around w/ keyboard or mouse, pick your file, you're zoomed back in and focused on one file at a time, completely modal.

4:41:14 AM aristidesfl: I personally don't like expose

4:41:42 AM aristidesfl: I think it is slower than the application list

4:41:47 AM aristidesfl: or window list

4:41:51 AM aristidesfl: or typing

4:41:56 AM codykrieger: As cool as I think that idea is, it might be a little too different for the majority of people who are going to be using Kod.

4:42:14 AM aristidesfl: and there is another problem

4:42:35 AM aristidesfl: the reason expose works on mac is widows are different

4:42:43 AM aristidesfl: code windows are code windows

4:42:59 AM aristidesfl: onde they are miniaturized its hard to distinguish them

4:43:26 AM aristidesfl: what if

4:43:46 AM aristidesfl: each folder (project) has his own tab, and the files that belong to that project open in the same tab in the side bar a la espresso

4:44:16 AM aristidesfl: and if you open a single file that doesn't belong to the folder/project it opens in a different tab

4:44:33 AM codykrieger: I think that just adds unnecessarily vertical bloat to the window. I'd just open a separate Kod window for a separate project.

4:44:53 AM codykrieger: unnecessary*

puls left the room (quit: Ping timeout: 264 seconds). (4:45:05 AM)

4:45:07 AM aristidesfl: by vertical bloat wou mean?

4:45:35 AM codykrieger: The extra amount of vertical space taken up by the tab bar - 90% of people are only going to be working on a single project at a time, most likely.

4:45:38 AM sivel: if kod starts focusing that much on "projects" it will end up being just another code editor that no one wants to use.  I think what is going to make this special is if it maintains itself as a simple minimalistic code editor

4:45:52 AM codykrieger: Right, that's what I think as well.

4:46:08 AM aristidesfl: ok forget the projects

4:46:16 AM aristidesfl: replace that with folders

4:46:27 AM aristidesfl: codykrieger: the tabs are optional

4:47:00 AM aristidesfl: if there is only one tab it could diappear

4:47:06 AM aristidesfl: and be only the window

4:47:48 AM aristidesfl: the advantage I see in having tabs instead of windows is that navigating between windows of the same aplication is not that fast

4:48:00 AM aristidesfl: not that organized

4:48:18 AM aristidesfl: that is why most people like tabs browsers

4:48:36 AM codykrieger: Right, but again, the focus is on the text editor, not necessarily Kod's ability to handle folders and projects.

4:49:48 AM codykrieger: It just first and foremost be a great text editor. Able to be used for a single file very easily, and also just as easy to open a folder with it and work on multiple files. But much past that I think is outside the scope of what Kod is.

4:51:05 AM aristidesfl: sure

4:52:27 AM aristidesfl: but you have already lots of fast text editors

4:52:34 AM aristidesfl: use text edit

4:52:37 AM aristidesfl: its fast

4:52:47 AM codykrieger: But it's not a programmers' text editor.

4:52:52 AM aristidesfl: use textmate

4:53:02 AM aristidesfl: use vim

4:53:09 AM aristidesfl: emacs?

puls [~pu...@c-69-181-30-70.hsd1.ca.comcast.net] entered the room. (4:53:50 AM)

4:53:54 AM aristidesfl: what I mean is 

4:54:12 AM aristidesfl: everyone has their ones hopes about code 

4:54:28 AM aristidesfl: and they want to see they feature fulfilled

4:54:40 AM aristidesfl: if they don't bring compromise 

4:54:55 AM aristidesfl: I don't see any reason not to make them happen

4:55:32 AM codykrieger: It just seems too IDE-ish when that's not Kod's primary focus.

4:57:25 AM aristidesfl: come one

4:57:47 AM aristidesfl: it becomes an IDE because it can handle mode that one folder?

puls left the room (quit: Ping timeout: 240 seconds). (4:58:03 AM)

4:58:06 AM aristidesfl: http://☁.ws/䘶 

puls [~pu...@184-194-202-37.pools.spcsdns.net] entered the room. (4:58:10 AM)

4:58:18 AM aristidesfl: 11 files

4:58:29 AM aristidesfl: vertical vs horizontal roganization

4:59:15 AM aristidesfl: tabs look better

4:59:21 AM aristidesfl: but try to find something there

4:59:42 AM codykrieger: Sure, but that doesn't handle the multiple folders thing

5:00:04 AM aristidesfl: it doesn't

5:00:29 AM aristidesfl: 2 different battles

5:00:49 AM aristidesfl: the 2nd battle is

5:01:03 AM aristidesfl: tabs really work well when there are not too many

5:01:17 AM codykrieger: Right, because like I said before, I'm not opposed to vertical navigation. But I do like the tabs.

5:01:26 AM aristidesfl: and so maybe it makes sense to use them to something else

5:02:01 AM aristidesfl: you could still deatach them

5:02:37 AM codykrieger: I think if we ditch tabs for files, we ditch tabs entirely. No point in keeping them just to add multiple projects functionality. That's the whole point of window separation.

5:03:44 AM aristidesfl: I think the main point of window separation if so be able to put them in different monitors or compare files side by side

5:04:10 AM aristidesfl: you could still use tabs

5:04:15 AM aristidesfl: when you open files manually

5:05:16 AM aristidesfl: vertical tabs would be working only when working on a folder and the sidebar is therefore active

5:06:10 AM aristidesfl: fuck

5:06:12 AM codykrieger: Then we've got two completely separate and distinct ways of managing files with Kod, which flies in the face of minimalism.

5:06:14 AM aristidesfl: 5 in the morning

5:06:21 AM codykrieger: lol it's only 11pm here

5:06:45 AM aristidesfl: that is true

5:06:52 AM aristidesfl: not very minimalistic..

5:07:10 AM aristidesfl: but then… remove

5:07:14 AM aristidesfl: the tree

5:07:22 AM aristidesfl: start removing things

5:07:32 AM aristidesfl: and it gets more minimalistic

5:08:03 AM aristidesfl: but I see what you mean

5:08:18 AM codykrieger: Yeah I mean that's really my biggest concern with an approach like that.

5:08:45 AM aristidesfl: the way I see tabs

5:08:54 AM aristidesfl: is just a whay of grouping windows

5:09:06 AM aristidesfl: you have different windows

5:09:24 AM aristidesfl: and you can actually put them on top of each other

5:09:26 AM aristidesfl: like tabs

5:09:44 AM aristidesfl: that is what a tab shoud be 

5:09:47 AM aristidesfl: a window

5:09:50 AM aristidesfl: not a file

5:10:01 AM aristidesfl: files belong to the sidebar

5:10:38 AM aristidesfl: but that is just one aproach

5:10:52 AM aristidesfl: that I think has potencial

5:11:14 AM codykrieger: The issue then becomes, what happens when you hit cmd+t? Where does the sidebar open to by default?

damon__jones left the room. (5:11:50 AM)

5:11:56 AM codykrieger: All of a sudden cmd+t has a lot more meaning behind it, which could be totally unexpected by the user.

5:12:14 AM aristidesfl: well

5:12:19 AM aristidesfl: that is a ™ thing

5:12:23 AM aristidesfl: textmate

5:12:30 AM codykrieger: cmd+t no longer means just opening up a fresh blank file, it means opening an entirely new "project"

5:12:33 AM aristidesfl: in tabs world

5:12:41 AM aristidesfl: cmd tab means: new tab

5:12:54 AM aristidesfl: forget projects

5:13:07 AM aristidesfl: in a new tab you can open whatever you want

5:13:21 AM aristidesfl: file, folder, webpage,

5:13:36 AM aristidesfl: there are no projects

5:14:00 AM codykrieger: I'm using folder and project interchangeably - same difference to me.

5:14:37 AM aristidesfl: sure I'm just worried about the connotations the word projects brings attached

--
You received this message because you are subscribed to the Google
Groups "Kod.app" group. To unsubscribe from this group, send email to
kod-app+u...@googlegroups.com (More info at http://groups.google.com/group/kod-app)

[Bryan Swift]

Personally I really like the option IntelliJ has of "keep at most this many tabs open". So if I open more than (in my case) 7 files it will close the one that was active longest ago. This has not been a problem for me because I'm rarely working or looking at more than 3 files at once and because it is so easy to open a file I need.

Of course I think a language aware feature for opening files like the cloud bubbles of opening a file but method or IntelliJ's open file by class name is incredibly useful when tabs are automatically closed because it makes it so easy to get a file open. The same is true of TextMate's Cmd+T file opening.

[Ryan Spaulding]

It sounds like Espresso is a lot like screen. I currently use a
combination of screen and vim to do my editing of remote and local
files. I label each one of my vim windows this allows me to switch to
any vim session with a few key strokes (you can just start your label
and screen does the right thing). When you are working on code you
focus on what is in front of you. If you need to open or switch to
another file then that file should be moved to your focus. I love tabs
but are they really useful ? I mean look my Chrome window has like 15
tabs open right now and I can't read the tab name. I usually put them
in an order so I can remember which one to switch too.

> > On Dec 28, 2010, at 11:25 PM, aristidesfl <aristide...@gmail.com> wrote:
>
> >  3:58:55 AM aristidesfl: rsms: I've been thinking about tabs lately
>
> > 3:59:13 AM aristidesfl: I think you did an awsome job with the chrome tabs
>
> > 3:59:52 AM aristidesfl: and I think they are the most beutiful and
> > functional tabs I ve seen so far
>
> > 3:59:54 AM aristidesfl: but
>
> > 4:00:12 AM aristidesfl: I'm wondering if they are the best solution
>
> > 4:00:15 AM aristidesfl: I mean
>
> > 4:00:36 AM aristidesfl: They are pretty intuitive and they are pretty much
> > the standard
>
> > 4:00:55 AM aristidesfl: and they work pretty well
>
> > 4:01:08 AM aristidesfl: (with a few files)
>
> > 4:01:25 AM aristidesfl: but when we pass the 7 barrier
>
> > 4:01:45 AM aristidesfl: they start to show their limitation
>
> > 4:01:51 AM codykrieger: I rather like them, they're wonderful. Already
> > loads better than TM's tabs...we just need a way to have them scroll.
>

> > jedivulcan_ [*~jedivulca@wikia/majorthomme*] entered the room. (4:01:56

> > dyer_ [*~dyer@unaffiliated/voxeojohn*] entered the room. (4:21:24 AM)

> ...
>
> read more »

[Jakub Suder]

Please, don't make tabs vertical, it's fine as it is now. If you take
the sidebar for tabs, you leave less space for project tree. And we
need both - something to see the list of all files in the project, and
something to switch between the files that you're working on right
now. If you have too many files open, well, that's what Cmd+W is for,
right? Unless you're working on a huge project-wide refactoring, you
usually don't work with 20-30 files at the same time, only on a few.
Once you finish that part of work, you make a commit, clean up your
tabs and start again.

And expose, are you kidding me?... Each time you want to switch
between files, you'd have to press a shortcut, look at miniatures of
files (which look the same from distance), move the cursor to one of
them and click it - how is that faster than pressing
Cmd+Alt+left/right? And if someone doesn't have two big screens, they
often need to switch back and forth between 2 or 3 tabs all the time
if they're working on 2 or 3 related files (like code and test)...
this is a very basic action and it needs to be fast and simple.

Also, I don't like the idea of opening separate projects in tabs and
then separate files of these projects in other tabs within those
tabs... that's probably too complicated. And loading every file from a
project into memory at startup is also obviously a bad idea - and even
if it wasn't, the purpose of tabs is not to limit the amount of data
that the editor has to load, it's to let you switch between a few
currently open files as quickly as possible.

And "you have already lots of fast text editors, use textmate" is a
bad argument - I think most people here would agree that what we're
looking for is something very similar to TextMate, just better. It's
not another Netbeans that we want, it's another TextMate.

(Sorry if I sound harsh, it's probably because I got woken up earlier
than I planned...)

JS

[Cody Krieger]

Agreed, I'm all for keeping tabs and the sidebar as is, like I said in the transcript. If you've got too many tabs open, close a few. No practical need to have that many open in the first place.

Many of us are indeed looking for something similar to TextMate but better - I don't necessarily think making two separate paradigms of how files and tabs and the sidebar work is a thing that needs being done to become better than TextMate. Just by not being vaporware, Kod is already better. It will continue to get better by continuing to enforce the minimalism and simplicity rules that I believe Rasmus has had in mind from the start, as we implement more features in the core and whatnot.

And the Exposé thing was just thrown out there to be thrown out there, no need to get all worked up about it. ;) I wasn't being that serious.

Cody

[Agos]

Replying here because I can't understand the discussion tree with the new google groups interface.

Have you heard of peepopen? While not related to gui, it relates to file opening: http://peepcode.com/products/peepopen

[Stephan Müller]

Two more ideas:

* a stack of recently uses files (of a project), like cmd-tab does for
apps.
it allows fast (and blind) switching between the currently used 3-4
files.

* use temporary tabs
I sometimes have to browse through several files, looking for a
certain
piece of information. In current editors, this leads to enormous
tab-overload. An option to auto-close a tab would be great.

Ane possible implementation: arrange the tabs by last recently used. A
keyboard shortcut allows you to "browse" thru. Single clicks (or
selection
with arrow keys) in the project tree will open the tab (all left)
temporally,
a double click (or enter) permanently.

This could be combined with the "at most X tabs" approach; just remove
the
ones on the right side.

[Gordon Fontenot]

I use PeepOpen for XCode and Textmate. It's fantastic (Although the XCode implementation is super hacky)

[Andy Lee]

On Dec 29, 2010, at 6:02 AM, Stephan Müller wrote:
> Two more ideas:
>
> * a stack of recently uses files (of a project), like cmd-tab does for
> apps.
> it allows fast (and blind) switching between the currently used 3-4
> files.

I like how in Xcode, by default, cmd-opt-Left and cmd-opt-Right used to go backward and forward in the history of opened files. They changed these defaults in a recent version so those keystrokes go backward and forward in the history of your editing position, which is more fine grained because you might jump around within a file any number of ways. I prefer the old way, so my Xcode has:

* cmd-opt-Left/Right = go to previous/next file in history (at the position where you were editing)
* cmd-opt-shift-Left/Right = go to next editing position in history

Note that the same file may occur multiple times in your history.

Between these keystrokes, the popup menu of open files, global search, and Open Quickly, I don't mind the absence of tabs in Xcode.

> * use temporary tabs
> I sometimes have to browse through several files, looking for a
> certain
> piece of information. In current editors, this leads to enormous
> tab-overload. An option to auto-close a tab would be great.
>
> Ane possible implementation: arrange the tabs by last recently used. A
> keyboard shortcut allows you to "browse" thru. Single clicks (or
> selection
> with arrow keys) in the project tree will open the tab (all left)
> temporally,
> a double click (or enter) permanently.
>
> This could be combined with the "at most X tabs" approach; just remove
> the
> ones on the right side.

Because Xcode doesn't use tabs, I never worry about tab overload, though I sometimes force-close files with cmd-shift-W to prune the files popup. Xcode has an "at most X files" option in the file popup menu, but I have it set to unlimited and it's never been a problem.

These are just suggestions. I think I would be pretty happy with a text editor that did things this way.

--Andy

[Cody Krieger]

PeepOpen and TextMate's "open quickly" thing are definitely things we should look at when developing ways to open files in a jiffy. cmd+t in TM is probably my most used shortcut because it's so useful (obviously the shortcut will need to be something different now that cmd+t means new tab in Kod).

On Wed, Dec 29, 2010 at 5:27 AM, Agos <ara...@gmail.com> wrote:

Replying here because I can't understand the discussion tree with the new google groups interface.

Have you heard of peepopen? While not related to gui, it relates to file opening: http://peepcode.com/products/peepopen

--

[Gordon Fontenot]

Or should the new-tab command be changed? I see myself using "Open Quickly" much more often than opening a new tab.

[Pascal]

Dr. Pascal LECLERC
Anesthésiste-Réanimateur
C.H.P. Claude Galien
20, route de Boussy
91480 Quincy sous Sénart
01 69 39 91 16
06 12 63 83 38
pak...@me.com

[Steve Conover]

On Tue, Dec 28, 2010 at 9:26 PM, Bryan Swift <bryan....@gmail.com> wrote:
> Personally I really like the option IntelliJ has of "keep at most this many
> tabs open". So if I open more than (in my case) 7 files it will close the
> one that was active longest ago. This has not been a problem for me because
> I'm rarely working or looking at more than 3 files at once and because it is
> so easy to open a file I need.

+1 Simple. Keep the tried and true tab metaphor. Make the files that
"fall off" available via something like TM Cmd+T or Intellij Ctl+E.

[Steve Conover]

And please give me something like Ctl+Cmd+W or Cmd+Option+W to close
all tabs except the current one, and Cmd+Shift+W to close all tabs.

[Jakub Suder]

I think "open new blank tab" doesn't make much sense here - it's
essential in a browser, where you open a new tab when you want to go
to a new site, but not in the context of a programmer's editor that
has a folder of files open and only opens files from that list in new
tabs. I'd change Cmd+T to work like in TextMate, and move "open new
blank tab" action to a different shortcut, if not remove it
altogether.

JS

[David Keegan]

I built from source and the sidebar is working now. The sidebar plus the tabs works great. All my project files in the sidebar and just the files I'm editing in the tabs.

One thing I ran into was if I closed the last tab I lost my sidebar session. It would be nice to add a warning about closing the last tab.

-Dave

[David Keegan]

I think new blank tab is useful for starting a new document or as a scratch board.

-Dave

[Gordon Fontenot]

I think that the new-tab feature is useful too, I just don't think it's as useful as often as the "open quickly" command.

[Walter Lee Davis]

I think that if you're in the context of a project, New (as in Apple -
N) should open a new file dialog which should include the path rooted
at the project root level and should create a new empty tab. This maps
to Control-click in the sidebar to create a new file at a specific
directory level within the project by direct manipulation.

Walter

On Dec 29, 2010, at 2:28 PM, Gordon Fontenot wrote:

> I think that the new-tab feature is useful too, I just don't think
> it's as useful as often as the "open quickly" command.
>

[Jim Puls]

Command-Shift-N, right? TextMate already does this.

-> jp

[Steve Conover]

What is it about Kod that pulls in so many people who don't read the
instructions, printed at the bottom of each and every email, for
removing themselves from the group?

On Wed, Dec 29, 2010 at 10:12 AM, Pascal <pak...@me.com> wrote:
>
> Dr. Pascal LECLERC
> Anesthésiste-Réanimateur
> C.H.P. Claude Galien
> 20, route de Boussy
> 91480 Quincy sous Sénart
> 01 69 39 91 16
> 06 12 63 83 38
> pak...@me.com
>

[Rhys Powell]

Here's another idea, hitting ⌘T opens a new tab with the cursor in the
omnibox at the top. If you have a folder open in the sidebar, it's
location will already be in the omnibox, if you've just got an
arbitrary file open then your home directory is used. You can simply
tab into the main field and start typing if you want to use the file
as a scratchpad or save it later. Alternately you can type a file path
into the omnibox, with terminal style tab-completion of course. If the
file exists, it will open on the new tab, if it doesn't the file will
be created and opened for editing in the current tab.

Also for creating new files perhaps a more explicit input should be
supplied, just hitting return could cause new files to be created when
the user makes a spelling error so perhaps use ⌘↩ instead?

---------------------
Rhys Powell AKA _frog
http://frogbot.co.cc/

[aristidesfl]

First of all sorry for posting the IRC log whiteout being properly formated and then stupidly deleting the post like it was not already sent to most of you.

Here are a few more words:

NOTE: If you never had the need to work with more than 3 files at once, this is not for you.

NOTE: This is absolutely not about Espresso, but it might be handy to download it order to understand what I'm talking about when I talk about it down there.

1. Why Tabs work.

Instead of tabs, we could have little buttons in the exact same place doing exactly the same thing. But we don't, because tabs make the user feel confortable. They are a good real world metaphor that translate a system that we are already used to, and that makes tabs feel so familiar that creates positive affection.

They just feels good

2. Acknowledging the limitation of tabs.

There are many examples of failed attempts in creating interfaces based on real world. One of them is BOB: http://☁.ws/microsoftbob

Tabs are a great example of a real world paradigm that doesn't fall in that category and works pretty well when translated into computers. 

Nevertheless, it has something in common with all of them. If fails at allowing the user to take full potential of the computer. It puts into the computer the same restrictions they have in the real world. You can't have more that a few of them without starting to be extremely inefficient to find anything.

So, maybe they are a good solution for normal things and normal users. But maybe not the best for someone who deals with big amount of files.

I know you might be thinking, "but only need a few files at a time..". Well that might be 1. because of the kind of projects you deal with, or/and 2. because you have no other option. you have to close files otherwise you get lost in the middle of them.

That is the reason most of experienced users, eventually realize that icon view in finder has limitations and start using some sort of list view most of the time. This is probably not a bad comparison to explain why Espresso approach is in my opinion a better solution for a programmers text editor.

Because it has less limitations that tabs. Sure, it doesn't feel so good, but finding something in a list of 15 items is faster that finding the same thing in a group 10 tabs. And the 15 list items seem like 10, while the 10 tabs feel like 20. Maybe I'm exaggerating (or maybe not) but you get the point. 

When dealing with more than a handfull of items, lists work better then icons(or tabs for that sake)

3. Tab management

Some other of you might say "tabs limitation is a good thing because it makes you KISS and prevents you from multitasking". That is simply not true. Less tabs simply means one of two things:  1. you work on less files, and write everything on the same files instead of separating things across files and end up with huge size unreadable files, or 2. you have to do tab management.

Tab management means having to think twice before opening a file and then having to close the tab once you realize that there is nothing interesting there. It means having to stop working when you can't find some tab because it is too bloated (with just a few tabs), figure out witch tabs you don't need anymore, and close them so that you can get back to those 3 or 4 manageable tabs. That is what I call limited (and btw that is what multitasking really means).

4. Tabs are the best invention ever! Why would someone want to take them from us? 

Tabs were the best invention ever. They are great for the reasons mentioned before, but browsers are the first to admit they have limitation and the first to start looking for alternatives.. chrome vertical tabs, tabs expose, firefox tabs groups.. etc. It's time to move on!

Kod is going to be the new kid in the block and there is no better opportunity to break the rules. No need to get attached to old paradigms just because textmate uses tabs. Textmate is not all good and we all know that, is has many flaws, otherwise we would not be here.

Don't get too attached to old things that might be slowing you down, even if you don't realize it now. Let it go.. (see Toy Story 3).

I remember when I saw the first cell phone. What a extravaganza.. and nice little that we don't really need.. Now we can't live without them.

And it happens the same with all new things and ideas. It's hard to see their potencial until we really start to use them. And it's really easy to reject them because just the idea of changing hurts.

Don't let that prevent you to evolve to something more powerful.

5. Do we have to get rid of tabs?

Maybe not. Maybe tabs have been being used all wrong until now. Maybe tabs should represent windows instead of files.

Sure that is not what happens in textmate, but hey, you can't create a window in textmate by dragging a tab, like you can in kod.

What happens when you have two folders open in two different kod windows and drag them into each other? What happens to the sidebar of each?

What happens when you drag a tab out of a project? What happens when you drag a window into a project where it doesn't belong to? Should each window only be allowed to have one project? What happens when you transform a window in a tab or vice versa?

Maybe it makes more sense to have tabs not represent necessarily files, but represent windows like in browsers, where you can open files or folders on it.

And when you open a folder you get a sidebar that works like espresso.(Click once a file to open it in the same tab/window. Click a file twice to save it in the quick access list aka workspace). We could get creative here, and even have a shortcut that opens the file in a new tab/window.

And then we could obviously have an option that makes it behave like in textmate for people that don't like it.. or the other way around..

6. The espresso approach

The reasons I like espresso approach are:

1. It is really cheap to scan through files to see their content because they open all in the same window and you don't have to close them after.

2. If you think you will be needing a file again you can double click to place it in a quick list in the sidebar.

3. It ends up taking less space then the tabs

Someone said that it is a bad idea because you loose space in the project tree. That is true, but:

1. The space you loose is not really significant because even if you put in the sidebar the maximum number of tabs I consider to be manageable in a 13 inch, lets say 7, you still have 31 (38 in total minus 7)  lines left for the project tree.

2. The space you loose in the project tree, you gain in the code. And in the end of the day it is all about the code.

3. The space you loose in the tree you gain in readability. Checkout this screenshot with 11 files: http://☁.ws/䘶 

Finally 

I'm sorry Mr. Tabs, I did't meant to ofended you with my words. I just think you are not being used to your full potential.

PS: I was hungry and in a hurry when I wrote this so might be difficult to understand some parts. Ask you can't understand something.

[aristidesfl]

Don't be afraid to try something new because you might actually never want come back!

[Agos]

I love tabs as much as the next guy, but aristides has ha point.

[Stephan Müller]

One more note to "vertical tabs": they are much easier to flick
through, since all the filenames are aligned.

I really understand the concerns about taking space from the project
tree. On the other hand, once you've opened the files you're working
on, its not needed anymore. And is a tree really the best solution we
can find? In a large project, it just needs too much space. What about
a column view? Or two separate modes, one for tabs, one for the file
tree?

The idea may be stupid; but I just think we shouldn't take anything
for given.

[Zach LeBar]

Wow. Nice write up aristides. Nice to see your thoughts in a more succinct way...other than the irc log.

I gotta admit, I didn't really see the need to mess with tabs in Kod, but you do bring up some good points. And so does Stephen. I mean, if we want Kod to really make a splash, maybe we should step back and take a look at what we're simply taking for granted.

- Zach LeBar

[Reed Stoner]

This sounds like a novel approach.

Reed Stoner

Sent from my iPhone

[Alexander Klimetschek]

Tabs are very nice and intuitive (since they are common in all
browsers nowadays), but only until a certain limit, which is something
between 5-10 tabs in today's screen resolutions and with longer
filenames. Anything above literally kills the concept.

All things to show more tabs, either make them devilish small, show a
drop down for all the out-of-bounds tabs (Eclipse, Safari) or even
multi-row tabs (Windows/Visual Studio), are hard to grasp, especially
if the algorithm to place the tabs in the active area is totally not
matching what you are currently looking for.

Hence I think the "vertical" tabs / workspace tree like in Espresso is
something to consider.

Regards,
Alex

[pjv]

+1 for the espresso approach instead of conventional [horizontal] tabs. it takes getting used to it, but after using it for a while, i prefer it.

of course it would be grand to offer both (conceptualized as something like an overall "workspace view") and a quick toggle between the two.

[Walter Lee Davis]

What about overflowing horizontal tabs into a column on the right when
they exceed the window width, or having two columns at the left, one
for the tree and the other for the "tabs"? There's lots more width
available on modern screens, and you might take advantage of that.

Walter

[Bryan Swift]

Just because there is more width available on the screen does not mean it's available to the editor. I may be in a minority but I don't do my editing full screen. I like to be able to see other things behind it, whether the page I'm working on, a photoshop document, a design document, or even (gasp!) my desktop.

 - Bryan

[Walter Lee Davis]

Point well taken.

One thing that bugs me about TM is that when I'm in the flow of
working, I may open up way more tabs than can fit. I don't like to
break my concentration by doing window management, yet I get lost with
the many related files in a Rails project, and find the overflow to be
difficult to manage. (Click and hold, then read each title, or --
hopefully -- look for the bullet meaning Not Saved.)

I think it would be great if the tabs that fit would be visible, and
if you got to the point where another would not fit, the oldest saved
tab would close, failing that, the oldest tab would close.

I'm not sure how I feel about the tabs shifting order though -- part
of the beauty of these real-world object maps is that they allow a
sort of short-term symbolic memory, so you don't have to do a full-
text search every time you want to switch to another file in your
project. (Second from the left, rather than somefile.html.erb.) If
auto-closing tabs changed that order, there might be too large a price
to pay for avoiding the overflow.

Walter

[Reed Stoner]

> Maybe it makes more sense to have tabs not represent necessarily files, but represent windows like in browsers, where you can open files or folders on it.
And when you open a folder you get a sidebar that works like
espresso.(Click once a file to open it in the same tab/window. Click a
file twice to save it in the quick access list aka workspace). We
could get creative here, and even have a shortcut that opens the file
in a new tab/window

I like this Idea, but I think it can be improved. If you change the
metaphor from 1 tab = 1 document to 1 tab = 1
project/folder/workspace and then combine the sidebar in with the
editor. This would allow a different tree for each tab. We could then
use some sort of visual indicator, something like a different
background color, to indicate which files are 'open'. This would keep
the number of tabs to a minimum to prevent tab overload and keeps the
focus on editing.

This is would be similar in style to Xcode, where the project stays in
a single window and the file icons turn gray to indicate changed and
unsaved files. This would help with greatly when you have multiple
projects, or multiple instances of the same project open. Instead of
the mess of open project windows you could combine the projects into
one window with multiple tabs. Additionally this lets you pull out a
project as a whole into a separate windows and build your own, saved,
custom workspace from files located in multiple locations.

You could also take aristidesfl's suggestion of an Espresso style
'double click to add to workspace' feature or something like the
Finder/iTunes with collapsable sections for things like file
shortcuts, smart folders, and custom searches viewable in all
sidebars.

Reed

[Swizec Teller]

When tabs close the memory shortcut "second from the left" quickly fails. Whereas if they just get squished together, it doesn't.

Personally I love tabs and wouldn't go away from them for any price. I only use them as visual cues for the "second from x" or "somewhere in the middle-ish". The result of this is that I can easily handle a browser with 30+ tabs open and it doesn't get difficult. I don't really care what it says in there. Some sort of icon is enough. Don't care for the text.

Another thing I do is group tabs pertaining to a particular "task" into windows, so I have many windows for the same text editor open and then I can just switch between them with expose.

Anything that nests levels of complexity would, honestly, hurt my brain and probably cause me not to use that editor. It's part of the reason I hate IDE's. Why do I need to have tabs to represent open files and then something vertical to represent maybe open files that happen to somehow relate to what the IDE thinks I'm doing?

And that screenshot someone posted was what I would consider the worst UX nightmare ...

Cheers,

~Swizec

On 30 December 2010 19:11, Walter Lee Davis <wa...@wdstudio.com> wrote:

Point well taken.

One thing that bugs me about TM is that when I'm in the flow of working, I may open up way more tabs than can fit. I don't like to break my concentration by doing window management, yet I get lost with the many related files in a Rails project, and find the overflow to be difficult to manage. (Click and hold, then read each title, or -- hopefully -- look for the bullet meaning Not Saved.)

I think it would be great if the tabs that fit would be visible, and if you got to the point where another would not fit, the oldest saved tab would close, failing that, the oldest tab would close.

I'm not sure how I feel about the tabs shifting order though -- part of the beauty of these real-world object maps is that they allow a sort of short-term symbolic memory, so you don't have to do a full-text search every time you want to switch to another file in your project. (Second from the left, rather than somefile.html.erb.) If auto-closing tabs changed that order, there might be too large a price to pay for avoiding the overflow.

[Stephan Müller]

> Personally I love tabs and wouldn't go away from them for any price. I only
> use them as visual cues for the "second from x" or "somewhere in the
> middle-ish". The result of this is that I can easily handle a browser with
> 30+ tabs open and it doesn't get difficult. I don't really care what it says
> in there. Some sort of icon is enough. Don't care for the text.

And that wouldn't be possible if the tabs were vertical instead of
horizontal?

> Another thing I do is group tabs pertaining to a particular "task" into
> windows, so I have many windows for the same text editor open and then I can
> just switch between them with expose.

Thats for browsers. In text editors, this task most likely the
project, and gets its own window right when you open its folder.

However, I don't think its a good idea to make a tab for each project
(like Reed proposed). In most cases, you will be working on only
working on one project at a time, switching rarely, and have at most 3
or 4 projects open. Its easy enough to manage those with features
already available in the system, like expose, minimization or the
"application windows cycle" shortcut. IMO, to use tabs for this would
be a waste of screen estate.

Also, how would we deal with files without projects? Do they get their
own project-tab? What if we wanted to view two files at once?

> And that screenshot someone posted was what I would consider the worst UX
> nightmare ...

Supposing you're talking about this:
http://dl.dropbox.com/u/4700116/screenshot4h56m45s.png

I'm pretty sure, the purpose of the screenshot was to show how
espresso manages to arrange the same project with the same open
windows much more clearly. The two windows were just overlapping for
better comparison.

[Swizec Teller]

On 30 December 2010 23:42, Stephan Müller <mueller...@gmail.com> wrote:

> Personally I love tabs and wouldn't go away from them for any price. I only
> use them as visual cues for the "second from x" or "somewhere in the
> middle-ish". The result of this is that I can easily handle a browser with
> 30+ tabs open and it doesn't get difficult. I don't really care what it says
> in there. Some sort of icon is enough. Don't care for the text.

And that wouldn't be possible if the tabs were vertical instead of
horizontal?

Maybe, but for some reason I just don't like having things left or right of my code.

Never quite figured it out why, it just feels very very weird. Even when I'm using Xcode

I always edit files in their own window to get rid of the vertical file tree thing.

 

> Another thing I do is group tabs pertaining to a particular "task" into
> windows, so I have many windows for the same text editor open and then I can
> just switch between them with expose.

Thats for browsers. In text editors, this task most likely the
project, and gets its own window right when you open its folder.

However, I don't think its a good idea to make a tab for each project
(like Reed proposed). In most cases, you will be working on only
working on one project at a time, switching rarely, and have at most 3
or 4 projects open. Its easy enough to manage those with features
already available in the system, like expose, minimization or the
"application windows cycle" shortcut. IMO, to use tabs for this would
be a waste of screen estate.

Also, how would we deal with files without projects? Do they get their
own project-tab? What if we wanted to view two files at once?

> And that screenshot someone posted was what I would consider the worst UX
> nightmare ...

Supposing you're talking about this:
http://dl.dropbox.com/u/4700116/screenshot4h56m45s.png

I'm pretty sure, the purpose of the screenshot was to show how
espresso manages to arrange the same project with the same open
windows much more clearly. The two windows were just overlapping for
better comparison.

[Swizec Teller]

Sorry for double email, my client is acting up.

On 30 December 2010 23:42, Stephan Müller <mueller...@gmail.com> wrote:

> Personally I love tabs and wouldn't go away from them for any price. I only
> use them as visual cues for the "second from x" or "somewhere in the
> middle-ish". The result of this is that I can easily handle a browser with
> 30+ tabs open and it doesn't get difficult. I don't really care what it says
> in there. Some sort of icon is enough. Don't care for the text.

And that wouldn't be possible if the tabs were vertical instead of
horizontal?

Maybe, but for some reason I just don't like having things left or right of my code.

Never quite figured it out why, it just feels very very weird. Even when I'm using Xcode

I always edit files in their own window to get rid of the vertical file tree thing.

 

> Another thing I do is group tabs pertaining to a particular "task" into
> windows, so I have many windows for the same text editor open and then I can
> just switch between them with expose.

Thats for browsers. In text editors, this task most likely the
project, and gets its own window right when you open its folder.

Not really. I very very rarely work on the whole project at a time. Usually

I'm just working on a module that's built out of at most 10 files. I like using

the system where it's one window per module.

This is especially handy when doing django development because most

files use one of five-ish different names.

~Swizec

[Agos]

This is especially handy when doing django development because most

files use one of five-ish different names.

I know this :(

But to be fair any editor will have this problem 

[David Keegan]

I like the idea of the Expresso workspace but I don't really like it's implementation because the workspace and the file tree fight for space to display similar information.

What if the side bar allowed you to structure your files however you wanted? This is a feature I really like about xCode and it would be great to bring this to other code projects. I often find myself having to lay things out on the file system in a specific way for server or library restrictions. But this layout is often not the best for working with the code. It would be awesome to make the sidebar flexible so you could drag in files, directories and even urls and organize them into groups.

It would be awesome to allow plugins to register url handlers that would tell Kod how to interpret files from a url. For example the file:// url handler would deal with local files and tell Kod if something was a directory or a file and wrap file operations like rename, move, delete…

Another useful url file handler would be ftp. I've been working on a project this week that has server code for serving json and an iPhone app that reads that data. It would be awesome to be able to organize a workspace to display my server code and my iPhone classes together that abstracts away the fact that some of the files live on a server and some of the files are local.

Url handlers could be created for anything, http, gists, bitbucket and git repositories that allow you to view a repositories as directories and files without having to check them out.

The workspace can be edited within Kod but it would be awesome if the workspace file format was so simple it could be written or edited by hand too, something like this json:

[

"file:///home/projects/myproject/spec",

{

"label": "Code", 

"content": [

{

"label": "Server", 

"content": [

"ftp://host/var/www/php/myproject/mysql_config.php",

"ftp://host/var/www/php/myproject/mysql_to_json.php",

]

},

{

"label": "Client", 

"content": [

"ftp://host/var/www/static/myproject/javascript"

]

},

{

"label": "json",

"content": [

"http://projecturl.com/myproject/json",

"http://projecturl.com/myproject/json?callback=?"

]

}

]

},

{

"label": "Reference",

"content": [

"gist://345987",

"bitbucket://reference_project",

"kspace:///home/projects/previous_project",

"kspace://kod.com/kspace/comunity_references"

]

}

]

In this example the workspace pulls in a directory of spec documents, and creates some groups, defined by dictionaries, for organizing the server and client code and http urls for testing the json that's being generated. This way you can change the server code then switch files and see the result. There is also a Reference section that displays a related gist and a bitbucket repository for reference. It also contains another workspace of a previous related project and pulls in a workspace that's hosted online that could be a community or team pool of resources.

This workspace would look something like this in Kod: http://cl.ly/2T1T333X460o2F313z3D

What do you guys think? I've never seen a system quite like this and I think it would be great for todays coding environments that have related code that's spread out across servers, languages and platforms.

Dave

[Zach LeBar]

I like the idea here David. What you mentioned about potentially having custom views for the sidebar is an interesting one. Taking the approach of say an app like iTunes, and creating buckets to drop different types of files into, regardless of their location in the filesystem, sounds really interesting. I'd like to hear what others think about it. I know for me, I usually have the site brief or overview in one dir and my actual code in another, maybe some referenced script libraries off the server or something like that. I don't know, how would you guys use this type of structure? Does it sound more useful than just displaying a dir tree? I think it does. 

- Zach LeBar

[Stephan Müller]

> I like the idea of the Expresso workspace but I don't really like it's implementation because the workspace and the file tree fight for space to display similar information.

So do tabs and the the file tree. I don't think its a big problem, but
my previous idea (make two separate modes) would solve it. Espresso
allows to hide one or both.

> What if the side bar allowed you to structure your files however you wanted? This is a feature I really like about xCode and it would be great to bring this to other code projects. I often find myself having to lay things out on the file system in a specific way for server or library restrictions. But this layout is often not the best for working with the code. It would be awesome to make the sidebar flexible so you could drag in files, directories and even urls and organize them into groups.

I like the idea, but would rather see it implemented in a espresso
like way: you can freely arrange the files in your workspace. However,
this would require being able to save a project (with all its sidebar
configuration/list of open files).

If a workspace would allow folders, one could create one folder per
task (same file in several folders possible). One could even handle
the file tree just like any other workspace folder (but self-managed;
like a smart folder). Or make something like sidebar-tabs for task1,
task, file-tree, etc. (maybe call the tasks "workspaces" instead.)

It may also be helpful, if you could add files outside your project
directory to your workspace.

# Summary

project (window; saveable)
- several workspaces (folder)
-- individual files

"Smart workspaces" could allow to implement file-trees (several!),
recently opened files (and therefore simulate traditional tab
behavior), ... you could even write plugins for your own smart
workspaces!

[Agos]

This is really interesting, like it! :)

[Zach LeBar]

I agree. That sounds like an interesting idea. 

- Zach LeBar

On Dec 31, 2010, at 9:57 AM, Agos <ara...@gmail.com> wrote:

This is really interesting, like it! :)

--

[David Keegan]

> I like the idea, but would rather see it implemented in a espresso
> like way: you can freely arrange the files in your workspace. However,
> this would require being able to save a project (with all its sidebar
> configuration/list of open files).

The expresso way gives you a quick way to jump back to previously opened files, but what I'm advocating for is a decoupling of the sidebar tree view and the file system so you can organize your files and folders however you want and pull in resources from anywhere.

You could drag whatever you want into the side bar, local folders, files, ftp folders, gists, anything someone writes a plugin for. Things would be displayed as folders or files, for example if a gist was dragged in that contained only one file it would be displayed as that file, but if the gist contained multiple files it would be displayed as a folder, the plugin would decide this based on the data at the url. Groups could also be created and would act like folders but would only exist in the sidebar for organization, like groups in xCode. The sidebar layout could be saved out as a project, but you wouldn't need to save it to get this functionality.

Tabs or an expresso style workspace would still be useful for quickly jumping to previously opened files.

[pjv]

+1 - i like all of this: 

• the simple (human editable, scm-versionable) text-file underlying the structure and content of the sidebar
  
• the ability to visually drag&drop organize it however you want
  
• plugins to handle different kinds of sidebar content

really good ideas here.

[aristidesfl]

I like keegan3d idea, I'm just not sure I understood correctly..

1.

Let's suppose we are working in a folder called kod.

The sidebar would contain a default group called tree, displaying the folder contents.

You could create as many, or as few additional groups. 

In these groups you can put anything you want. They are just references to things inside the working folder. 

You could choose to replicate the espresso approach having just one extra group called workspace. 

Or you could get wild and create one group for each issue/feature you are working on, having the files related with that issue/feature in his respective group.

Fundamentally simple, powerfully flexible.

2.

In addition to files inside the working directory you could also have the possibility to drag into the sidebar external references that you might find useful or related to the project.

3.

The information about the sidebar (and eventually other preferences) could be saved in a hidden file in the working folder.

There are no projects, each folder can potentially be a project. Just like in git.

4.

If you are not working on a folder and you still want to take advantage of the sidebar to keep references, you can, in a temporary way. 

(Although I fail in finding a use case in which this would be useful, other people might

5.

I don't really see the lack of space in the sidebar a problem. 

The scroll seems to work pretty well in the editor, why not in the sidebar? We just have to scroll to the tree group if that is what we want to see.

In addition to that the groups can be collapsable just like the folders.

6.

It could feature a shortcut system a la Gmail labels to place things in groups and to access groups using keyboard.

The possibilities with the location bar, abbreviations and autocompletion are endless is just a matter of imagination.

[aristidesfl]

I just want to add that this solution (sidebar in general) would solve the problem being discussed in the Split editor discussion.

A click in a item in the sidebar would show the file in the side of the split where the caret is placed at the moment.

One could as easily show the same, or different files in each side of the split.

[Agos]

Hi aristidesfl, I have some observations about your (very interesting) post.

On Saturday, January 1, 2011 7:46:49 PM UTC+1, aristidesfl wrote:

2.

In addition to files inside the working directory you could also have the possibility to drag into the sidebar external references that you might find useful or related to the project.

This shows a limit of the relation between a directory and a “project” as envisioned by point 3. This is potentially very confusing! But could also be necessary.

 

4.

If you are not working on a folder and you still want to take advantage of the sidebar to keep references, you can, in a temporary way. 

(Although I fail in finding a use case in which this would be useful, other people might

This would introduce a mode, and a very dangerous one. An user could not be aware of which case he's in. Am I working in a folder? Am I not? In the latter case, information about the “project” might be lost without the user knowing.

5.

I don't really see the lack of space in the sidebar a problem. 

The scroll seems to work pretty well in the editor, why not in the sidebar? We just have to scroll to the tree group if that is what we want to see.

In addition to that the groups can be collapsable just like the folders.

An objection to this could be that the main panel is the content, while metacontent (the sidebar) should be sparser, shorter, etc. But as long as it remains an edge case there's no problem (most user would get along fine with just a file tree). Most important of all, scrolling in the sidebar is likely better than any solution for overflowing tabs.

 

6.

It could feature a shortcut system a la Gmail labels to place things in groups and to access groups using keyboard.

The possibilities with the location bar, abbreviations and autocompletion are endless is just a matter of imagination.

Automating grouping et similia would be very nice indeed. But I pose you a serious question: how would you navigate between items of a group, and groups? Switching between items wraps around the group, then another shortcut to switch group? Tabs have the useful property of being flat and sequential in an univocal matter. 

[Stephan Müller]

I think the sidebar, per default, should contain nothing (or contain a
user definable structure). If you open a folder by dragging it to the
Kod icon, it creates a new project, containing given folder in the
sidebar. It should be possible to drag other folders into the sidebar
as well; there is no main working folder.

There should be two kind of folders: smart, and regular.

Normal folders contain only references and are fully managed by the
user. They could also contain smart folders, or other regular folders
(although this would probably make the whole concept a lot more
complex). The sidebar "root" could be a regular folder. It could also
be possible to change the names of file references inside regular
folders (if you have several index.php files, for example). Maybe, the
filename should even contain the containing folder per default, in
such cases.

Smart folders should be fully programmable. The programmer should have
access to things like the file history (to implement tab-like
behavior) and the file currently being edited (show significant header
files), and handle sidebar events like file rename, move, delete and
provide additional context menu items for right clicks.
FTP Access could be implemented as smart folder. The Filesystem mapped
folders mentioned at the beginning could be implemented as smart
folders (it would be possible to rename and create files and folders
on the filesystem). You could take any of those folders and make your
own, better implementation. The possibilities would be awesome.

I like aristidesfls Idea of gmail like labels. They could make the
management of regular folders a lot easier. All files can be tagged
with several labels, and are added to the corresponding folder. There
could be an active label/folder in which one can access the first
couple of files directly with ctrl-1, ctrl-2 etc.

I dont think the project file should be hidden. Since the same folder
could be linked to several projects, the preferred configuration may
vary. Linked files outside the main project folder shouldn't be
temporary (e.g. external libraries). The file could also contain undo
information for files, so one can undo even after a crash or a reboot.
If we use a bundle, it could contain aliases of the linked files, so
they can be refered to even after they were moved on the file system.

On a different matter: I'm a little concerned about Rasmus not taking
part in this whole tab discussion. Maybe I'm a little confused about
the whole project structure, but isn't he still the head developer of
Kod and gets the final word on how things are done? The current tab
implementation looks like something he intended to be one of the big
and distinguishing features of Kod. I think we either need his support
on this, or should consider to start or fork our own project.

The current Tab interface could also be integrated in the new
approach: Just let the tabs represent one/any (smart) folder.
Open files wouldn't necessarily have their own tab, and to fully map
the sidebar functionality, the tab bar needs a "back button" and tabs
sometimes need to represent a folder. This may sound rather confusing,
but it doesn't need to be. One could for example build a configuration
that emulates exactly the same behavior we have in the builds right
now.

[aristidesfl]

On Saturday, January 1, 2011 9:59:18 PM UTC+1, Agos wrote:

Hi aristidesfl, I have some observations about your (very interesting) post.

On Saturday, January 1, 2011 7:46:49 PM UTC+1, aristidesfl wrote:

2.

In addition to files inside the working directory you could also have the possibility to drag into the sidebar external references that you might find useful or related to the project.

 

This shows a limit of the relation between a directory and a “project” as envisioned by point 3. This is potentially very confusing! But could also be necessary.

 

 

Well.. I thought about that for a while, and I think there are few things that make that behavior a better options. Let me explain.

IDEs vs Editors

While I think nobody nows what really distinguishes IDEs from editors, I would say everybody agrees that the reason they prefer editors is the speed.

Speed comes in various sizes and shapes: time to launch, responsiveness, number of steps taken to do something, etc..

For those people, that extra features in a IDE just don't justify the unresponsiveness and lack of speed.

Some of you might be already be thinking this is already pushing Kod a little bit in the IDE direction.

I don't really give a fuck if they cal kod an IDE or a editor as long as it does as much as he can without compromising speed. In a very elegant way. 

That is what I think is the key.

Folders vs Projects

Considering the previous idea, if this settings are not associated with a working folder, we definitely introduce a new element called project.

With that comes attached at least the steps of naming the project and having to save it somewhere.

That is bad since it reduces the speed and makes it harder to manage project files.

Some might even affirm that the word project is what distinguish an editor from an IDE.

On the other hand, if these setting are associated with a working folder, projects don't need to exist.

You only deal with folders like you would do in any editor. 

It's just that Kod happens to be really smart and remembers your state the last time you used it.

No complexity added, just smartness.

Besides that when you move a folder, for example by synchronizing it via dropbox, you don't have to worry about projects files. They just come along.

4.

If you are not working on a folder and you still want to take advantage of the sidebar to keep references, you can, in a temporary way. 

(Although I fail in finding a use case in which this would be useful, other people might

This would introduce a mode, and a very dangerous one. An user could not be aware of which case he's in. Am I working in a folder? Am I not? In the latter case, information about the “project” might be lost without the user knowing.

 

You are absolutely right. We should probably reserve the use of the sidebar for folders, since it is not very useful otherwise anyway.

If you are realistic, when you are working in something complex enough to take advantage of the sidebar, you have one main folder where your files reside. 

6.

It could feature a shortcut system a la Gmail labels to place things in groups and to access groups using keyboard.

The possibilities with the location bar, abbreviations and autocompletion are endless is just a matter of imagination.

Automating grouping et similia would be very nice indeed. But I pose you a serious question: how would you navigate between items of a group, and groups? Switching between items wraps around the group, then another shortcut to switch group? Tabs have the useful property of being flat and sequential in an univocal matter. 

Let me be clear, when I talked about gmail labels I was not being literal. I was just referring to the speed that their keyboard interface allow users to organize items.

Then although I understand that is important to think about all the possible problems of such a solution, I think keyboard interfaces are the least of the problems.

I could come up with some explanation right now, but I prefer not to because that is another discussion of his own and no advantage in starting it inside this one.

But there are lots of alternatives, only a matter of imagination: Type to search, flat sequencial with up and down, we could have a modifier key that makes up and down jump groups instead of files, we could make groups work just like folders making them collapse/expand with left and right.. etc..

[aristidesfl]

On Saturday, January 1, 2011 10:04:08 PM UTC+1, Stephan Müller wrote:

On a different matter: I'm a little concerned about Rasmus not taking
part in this whole tab discussion. Maybe I'm a little confused about
the whole project structure, but isn't he still the head developer of
Kod and gets the final word on how things are done? The current tab
implementation looks like something he intended to be one of the big
and distinguishing features of Kod. I think we either need his support
on this, or should consider to start or fork our own project.

I'm sorry not to comment further on the whole thing about smart folders because I could not understand very well some of the ideas (maybe I'm too tired from new year's eve).

Anyway I think some concepts have potential, and some of other I think have already talked about in the the reply to Agos.

Regarding Rasmus participation I've wondered about that also. 

But if you think about it, he is probably really busy with the administration and maybe he doesn't even have time to read this.

Or maybe he did but prefer to keep people discussing without influencing with his own opinion.

Maybe he is saving it for later.

Maybe he made up his mind already.

Maybe he thinks the idea ridiculous and doesn't give a fuck.

Maybe he doesn't feel the necessity to intervene since there is a lot of talk about it.

Maybe this is low priority.

Bottom line, he doesn't have to because like you said, the decision is all his, and this is nothing more that a discussion. No one is deciding anything here.

[Stephan Müller]

> *Folders vs Projects*

> Considering the previous idea, if this settings are not associated with a
> working folder, we definitely introduce a new element called project.
> With that comes attached at least the steps of naming the project and having
> to save it somewhere.
> That is bad since it reduces the speed and makes it harder to manage project
> files.
> Some might even affirm that the word project is what distinguish an editor
> from an IDE.

When I was telling about projects, I meant something like the projects
TextMate supports. Basically just a List of which Folders and Tabs (or
workspaces) are opened in the current window. It just exists, as soon
as you open any file. You don't need to save or name it, unless you
want to preserve your arrangement the next time you work on the
project.

[Carter Schonwald]

I think part of this discussion about the the notion of having a  ".kodproject" hidden file or folder are perhaps missing an important point / abstraction opportunity!

presumably there'll be things that'd be nice to have scripts compute  or log  per file that we'd like to locally keep with the file(s) that are related to them.possible examples might be an edit log for unlimited undo, precomputed trie lookup tables for autocompletions in a file that are dependent on whatever's in scope locally for that file / language etc.   (after all, a Trie data structure gives the fastest possible lookups for the set of all completions, right?)

isn't the actual need to have standardized flexible convention of where local meta / edit / whatever data about a file or group of files will be located that we can then subsequently ensure that once scripting facilities are added, they don't step on eachother?

so a simple strawman convention might be that in every folder where theres a file that kod has done stuff with there might be a ".kodata/" folder which has stuff like the urls for other directories that are in the same project, which dirctory has the "master" .kodata/ folder for that "project", plus local info like that files edit history and the like.

maybe this is too flexible, but it doesn't force a shoehorned convention onto everyone.

thoughts?

-Carter

[Agos]

On Sunday, January 2, 2011 9:30:02 PM UTC+1, Carter Schonwald wrote:

so a simple strawman convention might be that in every folder where theres a file that kod has done stuff with there might be a ".kodata/" folder which has stuff like the urls for other directories that are in the same project, which dirctory has the "master" .kodata/ folder for that "project", plus local info like that files edit history and the like.

maybe this is too flexible, but it doesn't force a shoehorned convention onto everyone.

thoughts?

Quick unrefined idea: make foobar.kodproject visible, but it's not just a file, it's a package, so you can put pretty much whatever you want in. Works fine for Logic, to name one. 

[Carter Schonwald]

@agos

the reason why i'd suggest the invisble .kodata/ thing as a default (for when theres not an explicit project file at least) is that theres a lot of potentially nice but user local data that might be nice to persist between kod sessions on a file (such as the unlimited undo), and it seems silly to pollute every directory with 1+ of these folders by default. Both have their places, and one in some sense is what might be explicitly kept under dvcs and the other might be local only.

-Carter

[Stephan Müller]

I think, we should have both. ".kodata" for stuff like unlimited undo
(for every window containing the given file), and a foobar.kodproject
file/bundle to save a window configuration (sidebar and open tabs), if
desired.

However, there should be a way to disable .kodata creation, if someone
doesn't want to pollute his folders. I would recommend a option to
always create and use .kodata, only use it if they exist, or ignore
them. There should also be a function to create .kodata folders
manually while in "only use if exists" mode.

The use of a foobar.kodproject file should be optional as well, since
many people might just want to use Kod as a normal text editor.

Subject change: We should probably create new posts for new subjects,
since this Thread is getting really long and off topic.

[lwe]

hey there

honestly why is a .kodata local directory required? this just clutters
directories, honestly I'm not missing any of those .svn directories
since switching to git - why not keep trie data, unlimited undo etc.
in Library/Application Support, sure - when the user moves a file
around we might not be able to get the data back, but using some
hashing algorithm or similar I suppose we could identify the file just
fine, even after moving around. Also the open tabs should not be
stored in kodproject, because they are per user or not?

and I totally agree with Stephan that kodproject should be optional
and not automatically created or anything, because that's a thing I
like about TM - I don't need a project.xml or pbxproj to be able to
hack on some files... on the other hand is a project file really
required? couldn't we just live with a sidebar which can be split
horizontally to display multiple structures? so e.g. on top it maps ~/
Projects/kod and on the bottom sftp://kodapp.com/didum/ and make use
of bookmarks (like a browser) to connect to remote filesystems.

[aristidesfl]

I would say too IDE-ish.. 

I might work for Logic and so, but Logic comes in a package of 8 DVDs (or something like that, you know what I mean).

 

[aristidesfl]

Subject change: We should probably create new posts for new subjects,
since this Thread is getting really long and off topic.

We should indeed  

[aristidesfl]

On Monday, January 3, 2011 11:30:25 AM UTC+1, lwe wrote:

hey there

honestly why is a .kodata local directory required? this just clutters
directories, honestly I'm not missing any of those .svn directories
since switching to git - why not keep trie data, unlimited undo etc.
in Library/Application Support, sure - when the user moves a file
around we might not be able to get the data back, but using some
hashing algorithm or similar I suppose we could identify the file just
fine, even after moving around.

I like this idea.

I think when working in a project (folder), it makes sense to keep in that folder a .kod just like git does because:

1. The probability of moving the whole folder as a project is very high, and we keep everything intact even in different machines.

2. It's just one .kod per project

3. There is actually data to store there that just makes sense in projects, like sidebar information.

Now there are features that would be nice to have in single files, even when we are not working in a project, like unlimited undo.

Is creating a local .kod file for each fucking file we edit in kod the best solution? I think the Application Support is better idea because:

1. Almost no one likes applications shitting everywhere, even if invisible files. One invisible per project already hurts a little bit.

2. If you move the file you loose the information, if the hash thing actually works, you can move them wherever you like.

3. You can even keep the information between machines by synchronizing the Application Support data.

The drawbacks I see are:

1. Does the hash matching works after renaming files? I don't know a lot about the subject.. maybe there is a way to do it so that it matches even if you rename or edit with another editor?

2. Having the Application Support folder growing and growing with information about files from 2 years ago. This is only actually a real problem if the data we keep there is big. Since we are talking about text files.. maybe it is not an issue.

That being said, the most reasonable approach (if the hash trick is feasible), is to keep in the Application Data all the information related to features of individual files, like the infinite undo (is there anything else? this is important).

When it comes to project information, keep it in the project folder just like git.

 

Also the open tabs should not be
stored in kodproject, because they are per user or not?

and I totally agree with Stephan that kodproject should be optional
and not automatically created or anything, because that's a thing I
like about TM - I don't need a project.xml or pbxproj to be able to
hack on some files...

You don't need them in TM and you would still not need them in Kod. 

They are a bonus, you don't need to think about them. They are just there to make Kod smarter.

(I'm talking about .kod invisible project file)

 

on the other hand is a project file really
required? couldn't we just live with a sidebar which can be split
horizontally to display multiple structures? so e.g. on top it maps ~/
Projects/kod and on the bottom sftp://kodapp.com/didum/ and make use
of bookmarks (like a browser) to connect to remote filesystems.

The question is not if project files are required or not. Is if they are useful or not. 

I say this, because there is almost no drawback in having them, since the user doesn't have to know they exist.

Since the usefulness of them was already discussed before (if you search in the discussion you will find the reasons), and there are no drawbacks... 

[aristidesfl]

On Monday, January 3, 2011 11:30:25 AM UTC+1, lwe wrote:

hey there

honestly why is a .kodata local directory required? this just clutters
directories, honestly I'm not missing any of those .svn directories
since switching to git - why not keep trie data, unlimited undo etc.
in Library/Application Support, sure - when the user moves a file
around we might not be able to get the data back, but using some
hashing algorithm or similar I suppose we could identify the file just
fine, even after moving around.

I like this idea.

I think when working in a project (folder), it makes sense to keep in that folder a .kod just like git does because:

1. The probability of moving the whole folder as a project is very high, and we keep everything intact even in different machines.

2. It's just one .kod per project

3. There is actually data to store there that just makes sense in projects, like sidebar information.

Now there are features that would be nice to have in single files, even when we are not working in a project, like unlimited undo.

Is creating a local .kod file for each fucking file we edit in kod the best solution? I think the Application Support is better idea because:

1. Almost no one likes applications shitting everywhere, even if invisible files. One invisible per project already hurts a little bit.

2. If you move the file you loose the information, if the hash thing actually works, you can move them wherever you like.

3. You can even keep the information between machines by synchronizing the Application Support data.

The drawbacks I see are:

1. Does the hash matching works after renaming files? I don't know a lot about the subject.. maybe there is a way to do it so that it matches even if you rename or edit with another editor?

2. Having the Application Support folder growing and growing with information about files from 2 years ago. This is only actually a real problem if the data we keep there is big. Since we are talking about text files.. maybe it is not an issue.

That being said, the most reasonable approach (if the hash trick is feasible), is to keep in the Application Data all the information related to features of individual files, like the infinite undo (is there anything else? this is important).

When it comes to project information, keep it in the project folder just like git.

 

Also the open tabs should not be

stored in kodproject, because they are per user or not?

and I totally agree with Stephan that kodproject should be optional
and not automatically created or anything, because that's a thing I
like about TM - I don't need a project.xml or pbxproj to be able to
hack on some files...

You don't need them in TM and you would still not need them in Kod. 

They are a bonus, you don't need to think about them. They are just there to make Kod smarter.

(I'm talking about .kod invisible project file)

 

on the other hand is a project file really

required? couldn't we just live with a sidebar which can be split
horizontally to display multiple structures? so e.g. on top it maps ~/
Projects/kod and on the bottom sftp://kodapp.com/didum/ and make use
of bookmarks (like a browser) to connect to remote filesystems.

The question is not if project files are required or not. Is if they are useful or not. 

I say this, because there is almost no drawback in having them, since the user doesn't have to know they exist.

Since the usefulness of them was already discussed before (if you search in the discussion you will find the reasons), and there are no drawbacks... 

[aristidesfl]

On Monday, January 3, 2011 11:30:25 AM UTC+1, lwe wrote:

hey there

honestly why is a .kodata local directory required? this just clutters
directories, honestly I'm not missing any of those .svn directories
since switching to git - why not keep trie data, unlimited undo etc.
in Library/Application Support, sure - when the user moves a file
around we might not be able to get the data back, but using some
hashing algorithm or similar I suppose we could identify the file just
fine, even after moving around.

I like this idea.

I think when working in a project (folder), it makes sense to keep in that folder a .kod just like git does because:

1. The probability of moving the whole folder as a project is very high, and we keep everything intact even in different machines.

2. It's just one .kod per project

3. There is actually data to store there that just makes sense in projects, like sidebar information.

Now there are features that would be nice to have in single files, even when we are not working in a project, like unlimited undo.

Is creating a local .kod file for each fucking file we edit in kod the best solution? I think the Application Support is better idea because:

1. Almost no one likes applications shitting everywhere, even if invisible files. One invisible per project already hurts a little bit.

2. If you move the file you loose the information, if the hash thing actually works, you can move them wherever you like.

3. You can even keep the information between machines by synchronizing the Application Support data.

The drawbacks I see are:

1. Does the hash matching works after renaming files? I don't know a lot about the subject.. maybe there is a way to do it so that it matches even if you rename or edit with another editor?

2. Having the Application Support folder growing and growing with information about files from 2 years ago. This is only actually a real problem if the data we keep there is big. Since we are talking about text files.. maybe it is not an issue.

That being said, the most reasonable approach (if the hash trick is feasible), is to keep in the Application Data all the information related to features of individual files, like the infinite undo (is there anything else? this is important).

When it comes to project information, keep it in the project folder just like git.

 

Also the open tabs should not be

stored in kodproject, because they are per user or not?

and I totally agree with Stephan that kodproject should be optional
and not automatically created or anything, because that's a thing I
like about TM - I don't need a project.xml or pbxproj to be able to
hack on some files...

You don't need them in TM and you would still not need them in Kod. 

They are a bonus, you don't need to think about them. They are just there to make Kod smarter.

(I'm talking about .kod invisible project file)

 

on the other hand is a project file really

required? couldn't we just live with a sidebar which can be split
horizontally to display multiple structures? so e.g. on top it maps ~/
Projects/kod and on the bottom sftp://kodapp.com/didum/ and make use
of bookmarks (like a browser) to connect to remote filesystems.

The question is not if project files are required or not. Is if they are useful or not. 

I say this, because there is almost no drawback in having them, since the user doesn't have to know they exist.

Since the usefulness of them was already discussed before (if you search in the discussion you will find the reasons), and there are no drawbacks... 

[Swizec Teller]

Perhaps I'm a bit daft, but what possible use for a .kod file is there anyway?

The most plausible thing I can find is the unlimited undo feature, which in light

of modern SCM tools is pretty damn useless. Plus I don't really think anyone

has a reasonable expectation of undo working beyond the current editing session.

As for the idea of keeping the text parse tree in the file so it doesn't have to

get recomputed every time a file is opened ... you're making a very dangerous

assumption here that Kod is the only editor ever to touch the file. You'd have

to recompute the whole tree on every start anyway.

Now, what about using a redis server that is run when the app is opened?

The benefits are that it's as fast as writing to memory and it doesn't pollute 

the directories at all. And for features like unlimited undo or whatever, it's got

native support for lists and such.

Although I'm still not convinced one would even need such a storage ...

Cheers

~Swizec

--

[Zach LeBar]

My assumption was that .kod would be used to keep the sidebar configuration between launches and projects. Something plugins could write to, etc. 

- Zach LeBar

[Carter Schonwald]

@stephan

I agree about having a switch to adjust whether or not something like the ".kodata/" hidden folder and the "blah.kodproject" folders of data are created. I agree that having BOTH  a "blah.kodproject" and ".kodata/" folders is sensible. one is for saying "heres a coherent group of files that I want you to group together for me" and the other is "heres data for the files in this folder that i'm doing stuff with, so that undo and other nice things act awesome!". The point being there should be a standard place for any plugins to locally store per file related data that would be useful to persist, not that such a local hidden folder is mandatory.

regarding the suggestions in some of the other replies:

putting the analogue of ".kodata/" per file into the application\ support/ folder strikes me a something of a memory leak unless ALL interaction with the file is managed via kod, which strikes me as making sense if the goal of kod was to supplant emacs as the OS that happens to also be an editor. Moreover, theres nothing to prevent part of the "close last tab that has a file open" behavior to have a hook that deletes the associated data in the hidden ".kodata/" folder.  The whole point is that it'd be nice way to locally store unlimited undos and other data generated from other plugins, and for those  who want it, a nice way of persisting that local data between editing sessions.  many editors create local hidden files that are per session or persist between sessions, emacs, vim  and many others whose names escape me.

cheers

-Carter

[Luc Heinrich]

On 30 déc. 2010, at 18:18, pjv wrote:

> +1 for the espresso approach instead of conventional [horizontal] tabs. it takes getting used to it, but after using it for a while, i prefer it.

FYI, the same kind of approach is currently tested for Firefox:

http://www.azarask.in/blog/post/firefoxnext-tabs-on-the-side/

--
Luc Heinrich - l...@honk-honk.com