Vanilla 1.1.1 is a product of Lussumo. More Information: Documentation, Community Support.
We are currently finishing the Bundle management features and we came with some controversial idea on how to solve the last problem. To the point: As some of you already know, we have two bundle folders, one in the root of the installation, and the second one in the user folder. Bundles in root folder are those which should not be changed directly by you, as a user. You are however encouraged to create the folder and the overriding item file in the user folder. When Intype is loading, it’s merging the two folders together, giving the user folder has higher priority. So in the end, you can change any bundle item (snippet, grammar, bundle menu) without touching the bundles that were installed with Intype. Also you won’t lost your changes when you install a new version of Intype, and also, you can simply backup all your changes.
However the mechanism we’re using for merging those two folders is using file name (and partial path) comparision so everything depends on a file name. Now the file names are made easily readable (like wrap_in_tags.itSnippet), because of lacking Bundle Editor functionality. With new Intype, we will deliver full bundle editor so you don’t have to mess with your files on the drive. However, for making things much safer for the merging mechanism, we would like to change the file names to universally unique identifiers. This will change all the names to something like this:
{3F2504E0-4F89-11D3-9A0C-0305E82C3301}.itSnippet
{88B0AFC5-9BA4-40C2-973B-389D23CA1729}.itSnippet
{E252374E-EBDA-45FD-8E0A-2AAC590D73B1}.itSnippet
Messy, isn’t it? So before you ask:
Now for what you get as a compensation:
Let us know your opinion about this, and if, let us know:
We’re looking forward for all your helpful replies and opinions.
Take care,
Intype Team
I’ve created about 12 or so of my own snippets, and edited about the same number.
Sadly, I didn’t know until just now about storing customized snippets in the user folder. All mine are scattered around within the built-in snippets :( No wonder I lose them every time a new install comes out.
I assume that in newer version of windows (Vista & Windows 7), the bundled bundles will go into ProgramFiles/Intype/... and the user folder will be in Documents/user/Intype/... or something, because normal users aren’t able to write to the ProgramFiles tree.
I’m not clear how this would change anything really – maybe I’m just being dense, but aren’t you still doing filename comparisons on startup – just with different (GUID based) filenames? How does this help anything, let alone startup performance? Are you intending to put all the files into a single folder, now that they’ll have guaranteed unique filenames, or what?
this sounds good.
i don’t mess to much with the bundles, only editing a little of a lot…
this scheme sounds good.
dflock: In 0.3.1 we are using standard file names generated from the title of the item. That makes the file names non-unique, and therefore vulnerable for invalid matching (there’s a high probability that for the same bundle, two people will create a snippet with the same name). To solve possible invalid matching we would need to add the GUID at least to the Jasmine file itself and do the matching on that information, BUT: we will have to not only scan, but also read and parse bundle item files from both folders (to get the GUID stored in the Jasmine), it is doable, but uselessly complicated. With the morning mind, I see I did not write it correctly in the initial post. I’ll change the “Significant improvement in startup performance.” to “Stay as fast as it is now.”.
It sounds reasonable to me.
Fyi, I created a bunch of snippets (around 20), updated a theme and edited the XML bundle.
keep it up,
Ben
It doesn’t matter to me. Better that way than having to sanitize the file names for the bundles (ie. I see lots of textmate bundles with chars like :, ?, etc in the filenames).
This is great as long as there is a way in the bundle editor to find out the uuid of a snippet
in the off chance there is a need to edit a itSnippet file manually. Not sure what those cases
would be it just might be helpful anyway.
@tstrokes: actually a button to “open snippet in intype” would do the trick?
@dflock, martin: I can confirm that Windows 7 build 7000 loads latest unstable Intype release fine, including handling the user bundles. The files are placed in:
\Users\<username>\AppData\Local\VirtualStore\Program Files\Intype\user
For the CodeIgniter bundle, there’s just shy of 390 snippets. I assume there will be a mechanism whereby I can set the starting UUIDs myself – or will they come internally from Intype?
I’ve edited some of the grammars, though I didn’t know about the users folder thing. Haven’t done anything with snippets.
How powerful is this bundle editor going to be? I’ve been trying to look for a JSP bundle to get (at least) proper syntax highlighting but can’t seem to find a good one. I’m currently having to use either the HTML or Java one depending on the file, but I’d basically like a merged version of those two for JSPs.
First off, thank you all for the hints.
tstrokes & dijon: Yes, it’s possible to add such functionality there. However, along the nice dialog-based editors for snippets, the bundle editor has it’s own embedded “source” editor in which you see the actual file of the bundle item. So in case of an syntax error in the original file, you can just click on “Source” tab, edit and save (item automatically reloads). The source window might show the path to the original file as well — just in case.
dijon: Thank you for the confirmation. About the user folder: Intype 0.3.5 does not install the user folder to the Program Files, but allows you to select where you want it. It defaults to standard user “Documents” folder. About the CodeIgniter bundle, we will definitely help you converting it either by a script, or by external command-line tool that will do the job for you.
estmatic: The bundle editor basically makes it easier to edit stuff. What you need is an update to the HTML to define a transition to Java inside <% and %> tags. Take a look at HTML grammar, and how this is done for PHP and Ruby there.
Sounds good – thanks for the updates Martin!
martin: I can help with writing a conversion script (to give you something less to do!) if you’d like. All I would need is guidelines on the UUIDs. Let me know if that’s something you’d like.
tstrokes: This is great as long as there is a way in the bundle editor to find out the uuid of a snippet
in the off chance there is a need to edit a itSnippet file manually. Not sure what those cases
would be it just might be helpful anyway.
martincohen: tstrokes & dijon: Yes, it’s possible to add such functionality there. However, along the nice dialog-based editors for snippets, the bundle editor has it’s own embedded “source” editor in which you see the actual file of the bundle item. So in case of an syntax error in the original file, you can just click on “Source” tab, edit and save (item automatically reloads). The source window might show the path to the original file as well — just in case.
The main use of showing the UUID somewhere, or rather, the main issue with your idea, is when it comes to sharing them. If I have a folder full of completely randomly named files, how do I know which I want to zip up and send to someone? I have to painstakingly work out the UUID of each snippet, and note it down. This wouldn’t be too much of an issue, if the string was but a little shorter.
I guess a work around would be to have an “export snippet(s)” feature, which would save them as normally named files, and an “import snippet(s)” feature which would load them in, generate a new UUID, and save them to the correct place with that name. Maybe that’s a little clunky though.
We’ve done some other research on this one, and the sharing (which we are trying to help with) is an issue that makes us think again. Some people have their snippets in SVN (the built-in bundles are there as well). Many developers are used to file editing/viewing concept. So the result is that the “middle golden road” would be to store the GUIDs inside the Jasmine and keep file names in readable form. Though, the file names will not be used for merging. Whole repository (both root and user folders) would need to be read and merged by the GUID. Once the repository is read from the Jasmine it will be cached in a binary form. Next time Intype is started it will read the repository from the cache (which will be much faster than scaning, reading and merging the Jasmine files). This cache will be automatically invalidated once you change something in the repository and generated again. Alhough this is a harder way to go with, it seems that it’s worth it. What do ya think?
You are missing the point where users are creating their own snippets. In that case the file name is generated from the title that user enters in Intype UI. In this point, we actually can handle possible conflicts (or unwanted overrides) against the Intype bundles. But what if we add to Intype snippet with the same name in the next release? There is more troubles, I’ve described in the initial post.
But what if we add to Intype snippet with the same name in the next release?
There are still ways to distinguish intype bundles from users’; first coming to my mind is adding a prefix (or a suffix) to the ‘system’ files, as in
%IntypeSnippets%\a_system_file.InType.itSnippet
Overriding snippets would involve adding the “InType” string to the file name of a user snippet (UI might ask on collision).
‘Regular’ snippets wouldn’t have that suffix, so if you added a new snippet with the next release, say ‘mysnippet.inType.itSnippet’, since no override had took place there would be no collision with the user’s ‘mysnippet.itSnippet’.
BTW, these are just a bunch of ideas I’m just throwing in.
You know, Vim or emacs have been doing this for years, and they always left the responsibility to the user; they don’t have a GUI editor, though.
Still, if you think the UUID solution is more viable, then go for it! :)
bye
Well, if there will be a different name (prefix, suffix) for user snippets, there’s another problem: Some users will produce bundles useful for others, and in this case, they would have to rename the items themselves instead of just packing to zip and publishing. I was considering this but found it too clumsy and not that elegant as using UUID (of course with a new variant described here).
I can’t help myself, and have to say this: Emacs and Vim are great editors with a long tradition, but we’re trying to achieve something else, something more close to a user, and still keeping up with tradition of Windows-like editors. My idea of UI is that if it’s possible to prevent errors automatically, I would go for it as hard as possible.
BTW. I’m glad you are sharing your ideas, that’s why I’ve opened this discussion. Keep it going.
I can’t help myself, and have to say this: Emacs and Vim are great editors with a long tradition, but we’re trying to achieve something else, something more close to a user, and still keeping up with tradition of Windows-like editors. My idea of UI is that if it’s possible to prevent errors automatically, I would go for it as hard as possible.
I can’t argue with this point; this is really the right direction. For every application.
The file name approach is of course quicker but obviously ‘dirtier’.
I’m really looking forward this new release (like everybody else here); good luck!
Thank you. :)
smmurf: In that case, be sure to backup your old bundles, reinstall intype and use one of the folder syncing / comparation tool to get those changed or new. Total Commander has such functionality.
I would vote for normal filenames with the GUID inside the file – you get human readability & GUIDs – what’s not to like?
baael: You will be able to setup where the user folder is. :)
I don’t really see why human readability of the bundle folders is an issue if there’s going to be a bundle editor. The only two things I would ask for are: 1) an import/export feature 2) a “Open bundle folder in Explorer” button or menu item
On the other hand, maybe you can just require bundles to have a file called “bundle.guid” or something which only contains a GUID. That way the bundle folder can be named whatever and intype isn’t slowed down heavily by having to parse through a file. Best of both worlds maybe?
estmatic: On the other hand, maybe you can just require bundles to have a file called “bundle.guid” or something which only contains a GUID. That way the bundle folder can be named whatever and intype isn’t slowed down heavily by having to parse through a file. Best of both worlds maybe?
You could just as easily have a comment as the first line of the bundle file. Then you just need to read in the one line, and you don’t need two files for every bundle.
estmatic: The problem with human readability that convinced me that it’s important issue are version control systems, where you see the file names. I’ve been asking some users myself and found that most of them are keeping their own snippets in SVN to synchronize their own snippets between home and work. The problem is not with bundles (folders), but the bundle items (files). The actual idea of a separate file to keep GUID is interesting, though. I’ll discuss it with the team.
baael: What I really hate on current applications is that developers are too often leaving their problems on users. As a developer, If you want make something easier for the user, it’s never easy for you. And important thing: enough alpha, let’s think about 1.0 to keep the delays in the future as short as possible. :)
1 to 33 of 33