Is there a reason why command+t and shift+command+t don't work the same way? It may be bad coding to have lots and lots of symbols in one document, but html files (and some js files) can get big and I'd like a good way of quickly navigating around the symbols.
Andreas
On 01/10/2005, at 16.22, Andreas Wahlin wrote:
Is there a reason why command+t and shift+command+t don't work the same way?
Shift-cmd-T was just a quick proof-of-concept (using the language grammars to capture symbols). It'll probably be more like cmd-T but move to the status bar (as a popup) -- it's one of the things on the 1.1 shortlist, but it's also one of those things I just really don't get why people need… ;)
Shift-cmd-T was just a quick proof-of-concept (using the language grammars to capture symbols). It'll probably be more like cmd-T but move to the status bar (as a popup) -- it's one of the things on the 1.1 shortlist, but it's also one of those things I just really don't get why people need… ;)
Don't ask, just do! No seriously, I have this js file with a class and it has LOTS of functions, like get/set stuff mostly ... and it's good to be able to navigate around that. I probably should have it all documented more properly, but this is a spare time project so I don't really feel like documenting to much, and then the symbol navigation thingie comes in handy for asking questions like "was it setHomeXY or was it just setXY, and what is the difference ..."
Andreas
On Sat, Oct 1, at 9:26 AM, Allan Odgaard wrote:
On 01/10/2005, at 16.22, Andreas Wahlin wrote:
Is there a reason why command+t and shift+command+t don't work the same way?
Shift-cmd-T was just a quick proof-of-concept (using the language grammars to capture symbols). It'll probably be more like cmd-T but move to the status bar (as a popup) -- it's one of the things on the 1.1 shortlist, but it's also one of those things I just really don't get why people need… ;)
I found that I rarely used the popup in XCode, and when I did it reminded me that my class was getting too big.
However I found that a constant display a la CodeBrowser in jEdit is much more helpful, especially when working through someone else's code. Could we not have a list view/tree view in a drawer, or for project windows make the project drawer into a split view and have one half of it display the symbols?
However there is another facet to this: If folding would just be a little enhanced so that the folded view is more compact (eg folds could eat up empty lines etc), I have found (at least in jEdit) that the folded view would let me navigate through code quickly. Of course it helped that jEdit can be configured to unfold all folds inside a fold when clicking on the fold marker.
So navigation would go like: Fold all, find method to go to, unfold that method.
Gerd
On 1 Oct 2005, at 17:21, Gerd Knops wrote:
However I found that a constant display a la CodeBrowser in jEdit is much more helpful, especially when working through someone else's code. Could we not have a list view/tree view in a drawer, or for project windows make the project drawer into a split view and have one half of it display the symbols?
Ooh, yeah, some sort of project symbol browser would be most excellent.
On 3 Oct 2005, at 10:12, Graeme Mathieson wrote:
Ooh, yeah, some sort of project symbol browser would be most excellent.
Of course, I'd forgotten that TmCodeBrowser[1] already exists... I blame spending too much time messing around with XHTML and not enough time getting to do real coding.
[1] http://www.cocoabits.com/TmCodeBrowser/
On 01/10/2005, at 18.21, Gerd Knops wrote:
However I found that a constant display a la CodeBrowser in jEdit is much more helpful, especially when working through someone else's code. Could we not have a list view/tree view in a drawer, or for project windows make the project drawer into a split view and have one half of it display the symbols?
So basically just adding TmCodeBrowser as a drawer in the opposite side of the normal file drawer?
I probably like the idea of the split with a detail view for the selected item the most, but just allowing a plugin to attach a drawer to the side would be a lot easier to do (and keep the content free form).
[...] Of course it helped that jEdit can be configured to unfold all folds inside a fold when clicking on the fold marker.
I am going to add the option click you requested rather soonish probably.
So basically just adding TmCodeBrowser as a drawer in the opposite side of the normal file drawer?
This would work good for me, but of course keeping the command+shift +t window/functionality as well?! It would also be nice to have it "searchable", as the normal command+t, but I've said that before.
I probably like the idea of the split with a detail view for the selected item the most, but just allowing a plugin to attach a drawer to the side would be a lot easier to do (and keep the content free form).
I don't think I quite understand your original idea here? Would you have some sort of simmilar list, and a click in that list will allow you to view that content only in the main area?
It would be really cool to have a DOM tree capabale side drawer, I suppose that is possible in some way by "emulating" it by interpreting the html code through rexexp wizardry ... perhaps the jEdit code could somehow be ported ..
Andreas
On Mon, Oct 3, at 6:28 AM, Allan Odgaard wrote:
On 01/10/2005, at 18.21, Gerd Knops wrote:
However I found that a constant display a la CodeBrowser in jEdit is much more helpful, especially when working through someone else's code. Could we not have a list view/tree view in a drawer, or for project windows make the project drawer into a split view and have one half of it display the symbols?
So basically just adding TmCodeBrowser as a drawer in the opposite side of the normal file drawer?
I probably like the idea of the split with a detail view for the selected item the most, but just allowing a plugin to attach a drawer to the side would be a lot easier to do (and keep the content free form).
Sounds good to me.
BTW jEdit's CodeBrowser uses a TreeView to group the 'types' ctags emits (eg functions, subroutines, classes, defines etc). And since display of some of these makes more sense than others, CodeBrowser keeps language-dependant defaults which of those types are unfolded and which are folded. That seems to work well, and may be something to keep in mind. Also when selecting an item, it not only jumps to that place in the code but also unfolds any folds potentially associated with the symbol.
[...] Of course it helped that jEdit can be configured to unfold all folds inside a fold when clicking on the fold marker.
I am going to add the option click you requested rather soonish probably.
YES :-))
Gerd
On Mon, Oct 3, at 6:28 AM, Allan Odgaard wrote:
On 01/10/2005, at 18.21, Gerd Knops wrote:
[...] Of course it helped that jEdit can be configured to unfold all folds inside a fold when clicking on the fold marker.
I am going to add the option click you requested rather soonish probably.
Actually if it were just me I'd say make click expand folds recursively (as in 99.99% that is what *I* want), and option-click just the top level. Though that would be inconsistent with for example how Cocoa handles Trees.
For jEdit I added an option to the preferences.
Of course ideally a user would have the same flexibility to configure mouse-buttons as with shortcuts, eg single/double/tripple click with modifier X in context Y would cause action Z.
Gerd
Gerd Knops wrote:
Of course ideally a user would have the same flexibility to configure mouse-buttons as with shortcuts, eg single/double/tripple click with modifier X in context Y would cause action Z.
That kind of thinking is exactly why most common users are staying away from Linux. Users generally don't want an overload of options. They want sensible defaults, with preferences to change common things. And maybe would you then add an advanced preferences thing where you would cater for the 1% of the users that wants to configure everything themselves ;)
Jeroen.
On Tue, Oct 4, at 1:30 AM, Jeroen van der Ham wrote:
Gerd Knops wrote:
Of course ideally a user would have the same flexibility to configure mouse-buttons as with shortcuts, eg single/double/ tripple click with modifier X in context Y would cause action Z.
That kind of thinking is exactly why most common users are staying away from Linux. Users generally don't want an overload of options. They want sensible defaults, with preferences to change common things. And maybe would you then add an advanced preferences thing where you would cater for the 1% of the users that wants to configure everything themselves ;)
I am sorry, but we are talking about a programmers text editor on this list. So I believe the audience is just a tad above 'most common users'.
TM is a program with which I spend many hours every day. I think my desire to be able to customize it to my needs is not at all unwarranted.
I agree that TM should come with a clean UI and sensible default settings as to not confuse the novice TM user (note that I am not saying 'novice user', we are still talking programmers).
But the demands are many. TM is used by application developers, Web site developers, Script developers, Manual authors, Java application developers, Microcode/assembler coders and many more. All of these tasks have somewhat differing requirements. Add to that preferences in coding style, and predisposition of users for 'mostly keyboard user' or 'visual user'.
All that flexibility requires a certain amount of configurability. Not necessarily visible from the UI, as an example just think of Key Bindings, which I am sure quite a few users modify for their needs.
Gerd
Allan Odgaard <allan@...> writes:
Shift-cmd-T was just a quick proof-of-concept (using the language grammars to capture symbols). It'll probably be more like cmd-T but move to the status bar (as a popup)
I really like the sound of this. Anything to keep my hands off the mouse.
-
Allan Odgaard -
Andreas Wahlin -
Gerd Knops -
Graeme Mathieson -
Jeroen van der Ham -
Scott McDowell