Code template service

[tito]

An idea for new service :

Imagine we have a repo with a lot of code template for many language, and can be accessible in pida ?

Code template service can :

• download from pida website last code template database
• replace some token in template (like name, surname, filename...)

Any comments ?

[ali]

+1

[aconbere]

tito and I talked for a while on IRC and we both disagree on best to make snippets/templates feasable. I think this is a great idea and a staple of many modern IDE's. I don't however think we should be tying it to and automatic update service, svn, or any other repository.

I see that having several main detracting factors.

1) adding large dependencies to the pida code install.

I know we all use the svn version now, but we're all developers of this application. I don't see any reason to presume that our average user will have that already installed on their machine.

2) complex online/offline handling.

Even in todays internet available world offline work is done around the globe, it's not unlikely that at least some of our users will be installing Pida with no internet access, and thus be denied a set of default snippets.

3) maintanence overheads.

We would then be tasked in maintaining a live repository that would be pulled from live at any moment. This would restrict any desires we might have of moving to a different VCS, and mean we had to keep a much more watchful eye on something that in the end is just a bunch of templates.

4) low value added

I think that the average developer will have 3 basic uses of snippets. He will want to a) use the pre built ones for doing things like making webpages with a prebuilt header. b) make his own for common repeating code segments, c) download other peoples snippets from the web. Having an online repository certainly seems to target (c) as means that any of us devs are capable of adding new snippets in and having them accessible to our users, but I question how productive that is when considering the amazing creative potential of the internet, and how little I know I want to write snippets.

If Tito is suggesting a site similar to addons.mozilla.org where users could submit NEW snippets and have them added to the repo, and can't help but be worried about the security implications there, or again the overhead in watching each on come through.

More realistic I think is a site like djangosnippets.org that allows you to paste your snippets, and offers them for download. Users can save the snippets to their machines, and we provide a "load new snippet" interface. They install it, their good. We interface with vim to making editing snippets easy, and we call it good.

[anonymous]

Well, I may as well add my 2 cents.

I beleive we need 2 things, one for small snippets, and one for larger multi-file snippets.

[aconbere]

So talking to Ali today it sounds like what's on the table now in terms of implimentation is variable access, and a general use case study.

More formally I would like to put down on paper what I feel are the important bits of snippets.

Snippet

A snippet is a templated section of code that is made easily re-usable through variable substitution. And example using the Jinja templating engine might be like as follows for formating code blocks.

"class {{ class_name }}({% if parent_name %}{{ parent_name }}{% else %}object{% endif %})
    """
    {{ doc_string }}
    """

which should be recognizable to all of us as the classic beginning of a new python class

Design Goals

1. Snippets should be easily Deployed.
2. Snippets should be easily Created, and Edited.
3. Snippets should be easily "Installed".

Implimentation

1. My idea on this is to have a directory of snippets, each snippet defined by a file. This will make creating new ones from scratch or using pida to create it's own templates easy. But this is sub optimal in user interaction, so possibly an "install" feature that would let you input a file and it would get moved there and associated with Pida, or an edit box (reuse a buffer?) that would save to the right place.

2. There is some contention on this point. So I'll try to elaborate my thoughts here.
   1. Ease of Creation:
      1. parsing variable names: The big win here for parsing variable names is template creation. We could do really cool things if you only parse the variable names. For instance you could select text in vim, click the "snippetize" button, and it would pull that text into another buffer or a special editor window where you can replace the stuff you want with variable names.
      2. explicit variable names: With explicit variable names you get things like "help text" and human readable names, but you loose the kind of one off flexibility that I think users are going to want. Users would have to do a lot more work even for the simple example I described below explicitly declaring 3 variable names, and their help text. This header information should be in a user editable format, so we'll have to parse that as well.
      3. My Suggestion: Allow for explicit declaration, this will be great for complex templates and built in templates so users can learn how they work, But make it optional! Most of our users aren't going to need help text to remember what "class_name" is in the template they built!
      4. I think there should be some discussion on the creation tools, as they are only slightly less important than implementation tools.
   2. Ease of editing: I'm torn between attempting to make a nice clean editing window or reusing a buffer, I'm interested in peoples thoughts here. Problems with a new buffer are that lots of editors aren't going to syntax highlight the templates very well, and it could be confusing to users to be shunted into a new buffer. Especially new users that may or may not be familiar with the buffers anyway.

3. I think it would be great to have a "pidasnippets.org" set up, and we could even use the open sourced Cab project from James Bennet of Django to do it. This would allow for all the features I can think of us wanting and make sharing snippets easy between users.

[ali]

I agree, let's write it.

[anonymous]

徐州玻璃瓶(鑫泰)总公司，始建于1985 年，原属玻璃瓶集体所有制，后改制为股份有限公司，下设：玻璃瓶厂、模具厂、包装厂。

[anonymous]

风幕柜 立式风幕柜 熟食柜 点菜柜

[ronny]

its too tricky to manage

i defer it from pida core to any 3rd party wanting to do it

[ronny]

Milestone snippet-plugin-1.0 deleted