On Fri, Aug 3, 2012 at 4:30 PM, Michal Suchanek <[email protected]> wrote:
> I don't think that doing this is desirable. fossil status should be
> fossil status.
>
And i agree entirely, i just posted the idea as a possible extension of the
custom commands (since this is an evolutionary process, and custom commands
will enable new directions for growth).
> You might want to write a separate script to replace it. It might be
> useful to be able to make fossil mystatus, too.
>
On my system it's "fst", but custom commands may (depending on the APIs we
would need to make scriptable) give users a way to completely customize
that, e.g.:
fossil my-stat
branch: foo
Edited:
foo.c
bar.c
Deleted:
baz.c
...
(That isn't currently possible because we don't (yet?) have th1 bindings
needed for those particular ops, but you get the idea.)
> browser attacks. But the same applies if you browse HTML documentation
> included in the project (or PDF documentation with overly clever PDF
> reader), or run projects build or other scripts, or run the binaries.
>
Absolutely agreed.
> Versioning them is probably a good idea.
>
And that will be done at some point. For prototyping i just use local files
because it's non-obtrusive and lets me concentrate on the templating system
and the required th1 APIs, rather than with the versioning and whatnot.
> Still if you are editing and
> testing the pages in the browser it might be good idea to make
> whatever you save a 'checkout' which is only synced when you 'commit'
> it. Otherwise you are going to make tons of small meaningless commits
> as you edit small details of templates and stylesheets.
>
This could be done using something like the wiki's preview feature, where
the client submits wiki content and the server renders it without saving it.
On a related note... with the JSON bits it would be really easy to add
per-user and/or per-login-session persistent data with JSON's rich data
structure complexity and strong data type support. So far there has not
been a truly compelling reason to add it (and it potentially adds db
maintenance overhead), so it has not been implemented [in fossil - i have
implemented it in another tree using the same JSON C library, and porting
it would be trivial]. Such a feature could, however, be used to store
drafts of wiki pages, templates, custom commands, or whatever custom UIs
need to save. Custom commands could even be given access to that data via
new TH1 bindings (which might be cool).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
