Sublime Forum

Layouts and others

#3

Different background can be useful if you are editing different kind of files, e.g. HTML files and source files. Color will be used to indicate type of file.
Itā€™s IMHO quite usefull since Sublime has built-in support for different layouts with a lot of files inside panel.
Picture as a background is a nice feature but I agree with you that it can be basis for discussion :wink:

Plugin with an UI is a platform to create more robust addons with better control of user interaction and without need to use very basic set of sublime UI controls.
For example if you are editing CSS file that plugin can display changes in graphically, just inside Sublime window (compare this with Stylizer http://www.skybound.ca).
It can be used to display any kind of data in simpy way, without using hard to understand DirectX interface. Just simple HTML file, with events (click, change, etc) connected to functions.
Consider the following example (itā€™s a prototype):
Python code:

class SampleUICommand(sublimeplugin.UICommand):
	def run(self, view, args):
		context = {'header' : 'Form header'}
		return sublimeplugin.UICommand.show(self, 'sample.html', context) or
		return sublimeplugin.UICommand.dock(self, 1, 'sample.html', context) # 1 is a number of pane

	@action('save_btn', 'click')
	def submit(self):
		form = self.forms.get('simple_form', {})
		fname = form.get('fname')
		lname = form.get('lname')
		sublime.messageBox(' '.join('Test on', fname, lname]))

and corresponding HTML:

<html>
<head>
	<link type="text/css" href="style.css" />
</head>
<body>
	<h2>${context.get('header')}</h2>
	<form action="#" id="simple_form">
		<label>Input first name:</label>
		<input type="text" name="fname"></input>
		<label>Input last name:</label>
		<input type="text" name="lname"></input>
		<input type="submit" id="save_btn"></input>
	</form>
	
	<script type="text/javascript" src="jquery.js" />
	<script type="text/javascript" src="script.js" />
</body>
</html>

I agree with because Iā€™m KISS maniac :wink:
I was Scite happy user (before I bought Sublime of course :wink:). This is a very nice and very simple editor. Butā€¦
Its simplicity is a problem because Sciteā€™s architecture is as simple as itself and doesnā€™t allow the programmer (Scite is provided with full source code) to do more than add another command as a external program with arguments. Sublime is much better but ā€¦ doesnā€™t allow us (programmers) to do more than use small subset of built-in functions :wink:
Stability is a good point to discussion but there are lot of applications with a HTML user interface (Firefox, IE, Outlook, Stylizer, etcā€¦) without big problems with stability (except IE :wink:).

Each of above are big and robust and terribly slow IDE.
I would like to add ability to define UI for plugins. HTML is one of that concept (and because of I have experience with that type of user interface in desktop applications :wink: ).

cheers
Artur

0 Likes

#4

Ok, I didnā€™t know about that :smile:

[quote=ā€œsublimatorā€]re:code folding
-1
What tgkeul said
[/quote]

vi/vim maniac :stuck_out_tongue:

[quote=ā€œsublimatorā€]re:file management (add/remove/delete)
-1
Just set up a launch console / ( file explorer of choice ) in current directory command.
[/quote]

Hmm, Iā€™ll try this.
But itā€™s sooo ā€¦ ascetic :wink:

Iā€™ll to this same using Pylons :wink: butā€¦
It would be better to have possibility to embed into Sublime window and control rectangular window/view (hide/show/resize/etcā€¦).
If Sublime will provide this functionality then it wouldnā€™t be a problem to display in this place HTML control or other GUI.
Provide functionality in the way Iā€™ve mentioned (MVC paradigm) before should be pretty simple.

Iā€™ve already known these project but the real problem is with integration browser control (IE or Mozilla based) into Sublime view.
The rest is just pretty simple :smile:

Awesome :smile:
Iā€™ve tried the same using the Pylons server but I think that both projects (CherryPy and Pylons) are too heavy, maybe lightweight WebPy would be a better choice?

Additionallyā€¦
What about displaying white spaces? Is it implemented ?
WScite has nice feature, called indentation guideline (in red rectangles):

It would be good to see the same in Sublime due to the fact that this is very useful in huge source code :smile:

cheers
Artur

0 Likes

#5

nice to see some fresh thought regarding sublime ( even i disagree with most of them :wink: ).

+1

in e text editor i remember that when you selected a block of text, it would mark tabs/enters/spaces. this was very nice.

0 Likes

#6
  • Code folding is on the todo list, although itā€™s not at the top.
  • Background images wonā€™t be appearing, not because Iā€™ve got anything against them, but because theyā€™re incompatible (without a significant speed hit, anyway) with the way text rendering works in Sublime when ClearType is turned on.
  • Iā€™m not a fan of adding support for manipulating files via the project management interface, nor adding a tree view to display the contents of the project. The former is better handled by dedicated file management tools, while the latter implies using a mouse to work with the project, which isnā€™t ideal. This isnā€™t to say Iā€™ve got anything against making the project support richer, but Iā€™d like to see it evolve in a way that complements a text editing centric approach, rather than taking the typical windows application approach.
  • GUI support for plugins is something that Iā€™ve had on my mind for a long time, but Iā€™m not sure thereā€™s any great answer here. HTML based UIs is one reasonable approach. In the short term, the likely next step for plugin GUI interaction will be a much improved input panel.
  • Session support is a great idea, and most of the supporting code is already there. The question is how to expose it in a reasonable manner: perhaps the most straight-forward is to have a one to one relationship between projects and sessions, but even that raises issues: if opening a project is the equivalent to opening a session, what should happen to the currently open files when a project is opened?
0 Likes

#7

Also, thanks for posting this - I do appreciate seeing feature suggestions

0 Likes

#8

ok

Ok, itā€™s enough clarification for me

[quote=ā€œjpsā€]- GUI support for plugins is something that Iā€™ve had on my mind for a long time, but Iā€™m not sure thereā€™s any great answer here. HTML based UIs is one reasonable approach. In the short term, the likely next step for plugin GUI interaction will be a much improved input panel.
[/quote]

Nice to hear this great news :smile:
Embedding some modern controls inside Sublime can be IMHO problematic due to the fact that Sublime is written in plain WinAPI as Iā€™ve already discovered.
In case of .NET we can simply use GeckoFX (http://code.google.com/p/geckofx/) to embed Firefox engine inside the application.
The whole idea is not to add big overhead to Sublime and make another IDE like Eclipse or Netbeans. It should be another application layer (like Python plugins now)
to allow the user to enhance built-in functionality with another one.
Implementation of such UI should be done on plugin API level so if some users want to keep it simple - they are not obligated to use new UI.

I think that KISS rule should be used :smile:
From my point of view session should be treated as a list opened files (despite projectā€™s membership) and should be stored as a single file.
It would be nice to save additional information in that file like bookmarks, folding in the future and so onā€¦

0 Likes

#9

Iā€™m appologize for reusing this topic :wink: but Iā€™have another question.
In other editors there support for Insert key.
Sublime works in different way - there are no difference between normal and Insert mode (and cursor remains the same).
Any suggestions?

0 Likes

#10

Just a thought but if the insert key is used, when in ā€˜replaceā€™ mode, it would be nice if it reverted back to insert mode when it hits a closing parenthesis, or, to be more general, when the current syntax context changes.

0 Likes

#11

Sessions differ from projects.
When Iā€™m working on a project with maybe 100 files I like to group some files in sessions to represent a certain aspect. Some of these correspond to bug tracks, some to business objects and their environment.

I used this feature a lot with multiedit years ago and missed it a lot. I had some Ideas to realize it myself but didnā€™t make it.

I suggest to use the sublime-session and allow the user to save the file with a name of his choice. We only need a save and a load command in the menu.

0 Likes

#12

Insert key is on the todo list - it hasnā€™t been a high priority, but as with anything else, if people want it more than I realise, Iā€™ll move it up the list.

re: sessions. Sessions currently contain a snapshot of all state: currently opened windows and their positions, as well as files opened within the windows, recently opened files, find history, etc. It would seem that not all of this is appropriate to serialise/restore if exposing the ability to load/save sessions: it likely doesnā€™t make sense to reposition the windows, for instance.

What should happen to currently opened files if you choose to load a session - are they closed, or do they remain open? What about new files that have been created but not yet saved?

0 Likes

#13

imo, the editor should never cause the user to loose his work, unless instructed so explicitly. so regarding new files or unsaved changes i think you must keep them open. if this is generalized, why closing any open file or window? it can be decided that loading a session will open new windows, i.e. we can see the current open windows/files as a new, temporary, session, and the loaded session as another. if we take this further, we now need to decide if this should be handled as a third session, or is it still 2 sessions (side by side). i would go with the simplest solution, seeing it as a new (3rd) session, so if saved, will contain all the windows/files/etc. states.

vim.

0 Likes

#14

I can see a few options for how it could work, none of which would result is the user losing any work:

#1: Changing sessions is like changing profiles: sessions contain the complete state of the editor (open files and their modifications, as well as open windows and their positions), and changing session will close all open files and switch entirely to the new one. This would work behind the scenes just like ā€˜File/Exit and preserve sessionā€™: state, such as unsaved changes to open files, would be saved in the session.

#2: Sessions apply to a window at a time only. Opening a new session will open a new window with that session. It allows multiple sessions to be open at the same time, but perhaps doesnā€™t make sense if you want one session to span multiple windows.

#3: Making sessions a bit ā€˜softerā€™: Opening a session closes all opened but un-modified files, while leaving modified files alone. Files that were open in the session are then opened. Window state, layout, find history etc arenā€™t touched.

I think #3 is my favourite, but Iā€™m not sure that any of the above are really satisfying.

0 Likes

#15

[quote=ā€œjpsā€]I can see a few options for how it could work, none of which would result is the user losing any work:

#1: Changing sessions is like changing profiles: sessions contain the complete state of the editor (open files and their modifications, as well as open windows and their positions), and changing session will close all open files and switch entirely to the new one. This would work behind the scenes just like ā€˜File/Exit and preserve sessionā€™: state, such as unsaved changes to open files, would be saved in the session.

#2: Sessions apply to a window at a time only. Opening a new session will open a new window with that session. It allows multiple sessions to be open at the same time, but perhaps doesnā€™t make sense if you want one session to span multiple windows.

#3: Making sessions a bit ā€˜softerā€™: Opening a session closes all opened but un-modified files, while leaving modified files alone. Files that were open in the session are then opened. Window state, layout, find history etc arenā€™t touched.

I think #3 is my favourite, but Iā€™m not sure that any of the above are really satisfying.[/quote]

I like #1, just like we have right now ā€œexit and preserve sessionā€, so +1 for #1!

This little feature has saved me a couple times already, I love the fact it saves unsaved files!
Sometimes I am recompiling information or just doing budgeting or quick notes whatever, I am glad sublime saves unsaved buffers which are (unexpected) shutdown/reboot friendly :smiley:
I feel safe using sublime text, I know my stuff is always going to be there! lol :smiley:

0 Likes

#16

I vote for #3, and the addition of a simple ā€œOpen session in new windowā€ or something like that.

0 Likes

#17

Yes I am aware of the plugin, very handy, but I just like the option to be able to have unsaved files ā€œsavedā€ in the session, without having an ā€œindividual fileā€ saved on disk for that buffer.
(I know the thing is saved on disk in session files [Auto Save Session.sublime-session, Session.sublime-session]), but this is automagically saved for me.

0 Likes

#18

If Iā€™m allowed to have favourite features, this would be one of them - Iā€™ve got unsaved files with notes etc that I started editing months ago, and have yet to get around to explicitly saving them.

0 Likes

#19

Nice, I might give it a go very soon :smiley:

Yup exactly my point! I got some unsaved files there too with phone numbers and quick notes that been sitting for months :smiley:

0 Likes

#20

Just an idea.

I would like to abondon the save command. Changes should always be saved immediatly without confirmation and the undo stack too.

Today, changes cannot be made undone after the file was saved and closed. On reopening all undo information is lost.
If the undo stack will be saved changes may then get undone when reopening the file.

Comming back to sessions, I vote for #1.

0 Likes

#21

Yeah - thereā€™s something to be said for providing some sort of persistent undo stack, but I donā€™t intend to change the way saving works, itā€™s just too different to justify imo.

0 Likes

#22

**+ 1 on this. ** Personally Iā€™d be happy to just have a FILE BROWSER in a little tree thing on the side!!

Please Please please. Just copy what E Editor / ultraedit/editplus/ie most other editors doā€¦ Itā€™s simple, it works, gets the job done and 99% of your new users will understand it.

A pane on the side which you can move, dock, pin(?) and importantly CLOSE) is, IMO, more elegant than pressing ctrl+alt+shift+o to bring a box which is arguably just an imitation of this same functionality anyway.

0 Likes