Good work, Bake. On 25/03/2008, Bake Timmons <[EMAIL PROTECTED]> wrote: > Since the new drivers page is not yet manually updatable, I just wanted > to give a heads up on the completion of these short sections: > > sh > sn > tc > uio > virtio > zorro > > These short sections were for more expedient testing of my new script, > which I hope to post here later today. > > One *inconsistency* that I see in the new drivers page is the missing > virtio directory. > > The rest of this email concerns an aspect of the KFV work process. > > The main holdup in posting my script is whether to add a new feature > that will be helpful but that will also complicate the KFV workflow, > namely the feature of *recursively* editing directory sections. E.g., > the Emacs script simplifies the viewing and editing of a table of > entries (might be screwed up under a non-fixed font) such as: > > ---------------------------------------------------------------------- > Comment ID & License All non-free Filename > (Enter License SW reported > 0=No Lic Text) (Y, N, n/a) > ---------------------- --------------- --------------- > 1 ? ? Makefile > Directory ? maple > Directory ? superhyway > ---------------------------------------------------------------------- > > I intend for the pressing of <C-return> on any of the above three lines > to do something useful. On the file here, it will pop up the contents > of Makefile with any initial comment highlighted and prompt for a choice > of license using a keyboard shortcut and fill in the table with the > proper info. This table is ultimately used to generate and upload the > appropriate wiki pages. > > Directories are another matter here. It seems to me that pressing > <C-return> on a directory entry should recursively start another table > which one can fill out. While this is a natural part of the workflow, > deep hierarchies might make it somewhat unwieldy, with several partially > completed tables floating around inside Emacs. > > I am tempted to just skip the feature for now and just post the script, > since is already quite helpful at this point. After all, another > sensible workflow is to work bottom-up, start with the deepest sections, > complete each one at a time, so that parent sections automatically > generate the right info for (finished) sub-directories. > > Indeed, I just thought of a good approach here. The main command is > kfv-start, which asks for a section URL on which to work, such as > > http://wiki.gnewsense.org/Kernel/Ubuntu-hardy-linux-2-6-24--drivers--sh > > Instead of jumping straight into a table with subdirectories, the > command could be modified to first present a reverse depth-first ordering of > the > section URLs, e.g., a little window showing just > > http://wiki.gnewsense.org/Kernel/Ubuntu-hardy-linux-2-6-24--drivers--sh-maple > > http://wiki.gnewsense.org/Kernel/Ubuntu-hardy-linux-2-6-24--drivers--sh-superhyway > http://wiki.gnewsense.org/Kernel/Ubuntu-hardy-linux-2-6-24--drivers--sh > > Then the user could simply run kfv-start on each of those sections > starting from the top. > > I plan to implement this and post the script today. As always, > comments, questions, etc. are gratefully accepted. > > > _______________________________________________ > gNewSense-users mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/gnewsense-users >
-- Reasons why you may want to try GNU/Linux: http://www.getgnulinux.org/ A great GNU/Linux distro: http://wiki.gnewsense.org/ _______________________________________________ gNewSense-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/gnewsense-users
