Re: some vim standard ? (stdlib.vim)
- On Sun, 2002-12-01 at 22:02, Sylvain Viart wrote:
>Vim help is sprinkled with some of these but a "Vim Standard Library
> I mean, it would probably interest developer to have a common
> library shared/tested/debugged/cvsized to be the base of any
> application development. Like functions in eval.txt in fact.
> It's the goal of open source sharing, isn't it ?
> I should probably ask my initial question this way :
> How should I write my code so developer can use/share/add/change
> the coding effort I've made ?
Guidelines" doc might be a good place to start. Here's a few of mine:
* Don't ever use <Esc>. It does different things depending on whether
insertmode is on or off.
* Always create insertmode mappings for those who use insertmode.
* Try to avoid loose script commands. Instead, always create functions
that do specific tasks when called.
* Try to have mode passed as an argument to main functions so calling
mappings, scripts or menus are forced to consider mode.
* Always scope functions and variables when not intended to be global.
* Always write script with &fileformat=unix. &fileformat=dos won't
work on unix.
* Never use Vim's abbreviated forms for commands or options. Always
use the full name since code readability is paramount!
* Always use spaces around operators and concatenation symbols.
* Don't glob normal commands on one line. Separate them into readable
* Never use the "l:" scope indicator within functions. It's redundant
Wow, that was fun! But see how quickly I degraded into personal
preference and style guide rather than "legitimate" library
guidelines? I'd be game to help on a stdlib.vim effort like this, but
I wonder if it would become ensnared in a similar bureaucracy. ;)
Steve Hall [ digitect@... ]
- On Sun, 01 Dec 2002 at 22:34:56 -0500, Steve Hall wrote:
> Vim help is sprinkled with some of these but a "Vim Standard Library
> Guidelines" doc might be a good place to start. Here's a few of mine:
>Sometimes the abbreviated forms are more readable, IMHO.
> * Never use Vim's abbreviated forms for commands or options. Always
> use the full name since code readability is paramount!
Examples: :abbrev, :exec, :hi, :e, and friends
> * Always use spaces around operators and concatenation symbols.This one also depends... sometimes it's more readable to cluster a small
group of related operators together without spaces, to keep them from
visually interfering with other operators.
Today's subliminal thought is:
- * On Sun, Dec 01, 2002 at 10:02:19PM -0500, Sylvain Viart <viart.sylvain@...> wrote:
> I've seen user documentation and that's very good. :)It depends. The rare plugins exposing functions to developpers often
> But I never seen developer documentation. And that's pretty normal,
> because script are rarely developed to be shared at development level.
> That's my opinion for now, I may be wrong.
have a documentation aimed at developpers. Somehow they are API plugins.
Other plugins don't have documentation about their functions as they are
not API-plugins. However, sometimes internal considerations are embedded
within the code for those who may wish to look at the code.
> > > May be a libbuilder would be a solution.I have misunderstood you. On an application level, supporting every
> > > Would it solve everyone preference ?
> > everyone preferences ? ... hardly I `think'.
> Could you give me case where a libbuilder will fail to solve people's
> problem about code inclusion / sharing ?
possible preference is quite impossible.
On an API level, what is a preference ?
Why does it concern the user ? Who is the user ? The VimL developper or
the end-user ?
It is very fuzzy.
The latest plugin I wrote (ui-functions.vim) defines several functions
aimed at plugin writers (or template-files writers). I think I can say
ui-functions.vim is an API-plugin.
At this time, the functions wraps VimL functions like |confirm()| to
interact with the user in :
- a gui-way (default behaviour when "has('gui_running')" is true)
- a text-ui-way (otherwise)
Depending on the current session characteristics or options set by the
end user, one of these two ways will be used.
Then, as I had a problem with |statusline|, I exposed it on this list.
Two other 'ways' were evoked. And I have two others in mind.
Unless I expose hooks, my functions can only propose a _finite_ number
> Of course the libbuilder need also an input strategy. It's not ourJust curious, have you checked |libcall()| ?
> problem for now, we are just guessing.
> > A tour on SF shows us a tendency to reinvent the wheel because of aIt is the same problem.
> > little something missing, or too many things unwanted, etc.
> Yes, that's true. But I'm speaking at API level not application level.
> [...]It is not really efficient or neat, but possible.
> An interesting question raise:
> Is vim designed to enable code share/reuse ?
For instance, as I do have several 'API'-plugins used by other scripts I
wrote, I often need to check dependencies are respected. As I can not
define a script that will check other scripts are installed (... snake
that bites its tail), every time I end up with:
- a function that display error messages (gui or text depending on
- a function that check a thing is defined (command, function, or
variable), if not try to source the file that is supposed to define
the thing (with runtime), it the thing is still not defined, then
an error message is displayed.
- several calls to the dependencies-checker function.
[Now, I'm thinking, this is a very good candidate for a template-file.]
> The difficulty to write a function which would give the name of theTry:
> sourced script in which a function was written may be a clue...
let s:script_name = expand('<sfile>')
Anyway, there are many low level stuff (ie aimed at plugin writters)
that I miss. So any step in this direction would be great.
Luc Hermitte, qui se doutait bien tu parlais aussi français. ~_^