Re: Snap rewrite #2

[Jaimos Skriletz]

On Thu, Dec 2, 2021 at 10:46 AM Dominik Vogt  wrote:
>
> This is about an accident during elastic paging development, but
> it feels "good" to me.  I've secretly always hated the "snapping"
> effect of snap attraction.  Windows jumping around is confusing,
> especially if the distance is big, e.g. if you use a "100" edge
> resistance.  So here is the new idea:
>

I like it when my window snap to edges/other windows. Though I also
like this idea as well, I can see both being useful. Is this going to
be configurable so a user can use the behavior they prefer?

jaimos

Re: Removig the "Emulate" command

[Jaimos Skriletz]

On Thu, Dec 2, 2021 at 6:15 AM Dominik Vogt  wrote:
>
> The command
>
>   emulate mwm
>
> has almost no effect.  I'd like to remove it.  There are only
> three things it controls:
>
> 1) The geometry window during move and resize is hard coded to the
>center of the screen.
>
>=> Give the window it's coordinates explicitly.

There is already a new GeometryWindow option which can control the
location of the geometry window. So this is now fully configurable
outside of the emulate options.

>
> 2) During an interactive placement, to tell fvwm that you want to
>resize the window after placement:
>  mwm mode:  press shift + button 1
>  fvwm mode: press button 2
>
>=> Just allow both.
>

Is this configurable via some binding. If not we should make the
button for this configurable via a binding, and just choose one for
the default behavior that can be changed.

> 3) Some weirdness about initial drawing of the wire frame.
>
>=> Remove that special case.  It makes zero sense.
>
> Opinions?

I'm unsure of any other problems here. I would just put some other
method to configure these aspects if there isn't already one in place.

jaimos

Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding

[Jaimos Skriletz]

On Sat, Nov 27, 2021 at 4:11 PM Dominik Vogt  wrote:
>
> On Sat, Nov 27, 2021 at 02:44:07PM -0700, Jaimos Skriletz wrote:
>
> > then FvwmButtons will resize to fit without preserving aspect ratio.
>
> FvwmButtons does honour the aspect ratio (see above).
>

If you set a geometry, *FvwmButtons: Geometry 100x100, the aspect
ratio hints do not get set (as in the default-config), and you can
resize the window to be any size. So it is possible to turn off the
aspect ratio hints to work with FvwmButtons.

> > At the time we chose to have it be disabled via just setting a
> > geometry string vs having an additional option to turn preserving
> > aspect ratio on/off. I would rather have an option to allow users to
> > toggle this vs just disable it.
>
> I disagree.  From experience, using the aspect ratio always annoys
> the user when resizing a window.  It's fine for initial size
> calcualtions, but after that, leave it to the user.  There are
> rare exceptions like video players.  It also causes uncommon
> problems like with sliding, swallowing in FvwmButtons, or using
> "maximize grow grow" in a script.
>
> Imposing limitations on the use of fvwm's modules is
> not the fvwm way of doing things.  FvwmPager is capable of dealing
> with any geometry, like all other modules.
>

I agree that we shouldn't impose limitations, which is why I think
this should be configurable (which it kinda is). That way the user can
turn on/off the option that resizing the pager honors the aspect ratio
of the screen or not. Though this should be something the user can
configure via an option in FvwmPager vs we decide for them based on if
they set a Geometry or not.

> New patch attached -> no problem with 1x1 pixels even when the
> desktop is 50x50.
>

I do like removing the size_inc hints, as there was a bug with
these/base_size hints vs the aspect ratio hints. So removing the base
size and size_inc hints would fix that.

In conclusion, if the aspect ratio hints also go it won't affect me
directly. But in terms of configurability, I still think an option
where the user can decide to preserve the aspect ratio when resizing
the window or not allows the most freedom for users.

jaimos

Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding

[Jaimos Skriletz]

On Sat, Nov 27, 2021 at 2:44 PM Jaimos Skriletz
 wrote:
>
> This can currently be disabled by proving an initial Geometry (though
> it needs to be bigger than some minimum size I recall like 100x100)
> then FvwmButtons will resize to fit without preserving aspect ratio.
>

I think I made it seem like 100x100 was the minimum size, this was
just some random suggestion (since it won't matter if FvwmButtons is
resizing it). Minimum size is 1 + height of desk titles.

Re: FvwmPager aspect ratio breaks FvwmButtons panel sliding

[Jaimos Skriletz]

On Sat, Nov 27, 2021 at 1:59 PM Dominik Vogt  wrote:
>
> From commit 601c5c294a6a48fd402fbfca02b62142796167eb
>
> >* Improved use of sizehints to set both minimum window size, and to
> >   preserve aspect ratio when resizing the pager. The aspect ratio is
> >   set to the initial size of the window unless the user sets window
> >   size with the Geometry option.
>
> x_pager.c:
> > + sizehints.flags = (sizehints.flags | PAspect);
> > + sizehints.min_aspect.x = sizehints.max_aspect.x = window_w;
> > + sizehints.min_aspect.y = sizehints.max_aspect.y = window_h;
>
> I'm against this change.
>
>  1) It breaks sliding the pager from a panel button.
>  2) fvwm's module were always supposed to deal with any size, even
> 1x1 or 65535x65535.

Not strictly true, there are some size increment hints that force the
pager's size to be an integer multiple of the number of pages shown,
so each page has the same number of pixels. So there were already some
restrictions on the sizes it could be.

>  3) It makes it virtually impossible to have the pager fill the whole
> allocated area inside FvwmButtons.

Can FvwmButtons be fixed to better deal with this?

> I see no benefit in these new limits.  Nobody resizes the pager
> manually, and insde FvwmButtons it's really harmful.  Can I remove
> this please?  (See attached patch.)

This can currently be disabled by proving an initial Geometry (though
it needs to be bigger than some minimum size I recall like 100x100)
then FvwmButtons will resize to fit without preserving aspect ratio.

At the time we chose to have it be disabled via just setting a
geometry string vs having an additional option to turn preserving
aspect ratio on/off. I would rather have an option to allow users to
toggle this vs just disable it.

jaimos

Re: Transforming program names

[Jaimos Skriletz]

On Thu, Nov 25, 2021 at 12:50 PM Dominik Vogt  wrote:
>
> Recently there was the question wether the "transform" logic aon
> man pages was still necessary.  It seems not.
>
>   --program-transform="s/fvwm/xyz/;s/Fvwm/Xyz/"
>
> Renames all man pages too:
>
>   fvwm*.1 -> xyz*.1
>   Fvwm*.1 -> Xyz*.1
>
> (The module names are not transformed, but that's a different
> topic.)
>
> It seems there is no need to change anything.
>

I use this for the Debian package, this way I can make fvwm 2.6.x and
fvwm3 installable side by side (to allow users choice). The manual
pages (and a few of the additional binaries like fvwm-menu-desktop)
are the main files that conflict. This just helps me not have to
manually in the debian packaging script. Currently works as I need.

jaimos

Re: Commit 3f61e78 breaks fvwm3 -v

[Jaimos Skriletz]

On Wed, Nov 24, 2021 at 5:41 AM Dominik Vogt  wrote:
>
> Fixed on master.
>

Thanks. No longer crashes here.

jaimos

Commit 3f61e78 breaks fvwm3 -v

[Jaimos Skriletz]

Hello,

On my system the following commit makes it so fvwm3 -v fails to start
on my system. But fvwm3 works just fine. I tracked the issue to this
commit, as this is the first commit in which fvwm3 -v no longer works
when running startx using a ~/.xsession file to launch fvwm3.

https://github.com/fvwmorg/fvwm3/commit/3f61e78201a452a69c74ccde036e371391e0dfd3

I am unable to figure out what is causing this to no longer work, but
the log file ~/.fvwm/fvwm3-output.log never gets created and
Xorg.0.log says Server terminated successfully (0). Closing log file.
So unsure if fvwm3 is crashing or just exiting for some reason.

jaimos

Re: Snapping issue

[Jaimos Skriletz]

On Sun, Nov 21, 2021 at 11:32 AM Jaimos Skriletz
 wrote:
>
> On Sun, Nov 21, 2021 at 2:09 AM Jaimos Skriletz
>  wrote:
> >
> > All of the updates have been pushed to js/snapattract.
> >
>
> I noticed a bug, though I think it is elsewhere in the code.

Arg, the bug was me, I wasn't typing my Style line correctly. Though
this did lead me to find an inconsistency between the manual page and
the actual code. The manual page states that for Style
EdgeMoveResistance:

The optional second parameter does the same as the first, but for
individual RandR screens. If omitted, the value of the first parameter
is assumed for this type of movement. Set the second parameter to 0 to
zero to ignore individual RandR screen edges.

This is not what I am experiencing. Instead if the optional second
parameter is omitted, the resistance between RandR screens is set to
zero (thus ignored), and this second parameter is needed to set any
resistance between RandR screens.

jaimos

Re: Snapping issue

[Jaimos Skriletz]

On Sun, Nov 21, 2021 at 2:09 AM Jaimos Skriletz
 wrote:
>
> All of the updates have been pushed to js/snapattract.
>

I noticed a bug, though I think it is elsewhere in the code. I was not
able to set the resistance to move a window between RandR screens
correctly. But if I modify the fw->edge_resistance_move block to apply
to all edges (change the last false in the DoSnapMonitor to a true),
the resistance does work between RandR screens. So to me this makes me
think that there is some issue with setting the
fw->edge_resistance_xinerama_move variable. Since the last block of
code in DoSnapAttract() is almost identical to the previous block of
code (which works), but uses a different variable for the snap
distance.

jaimos

Re: Snapping issue

[Jaimos Skriletz]

On Sat, Nov 20, 2021 at 5:22 PM Dominik Vogt  wrote:
>
>
> 1) Can we safely assume that the "bool" C type is available in
>every relevant compiler?

The bool type is used elsewhere in the fvwm code, so I would assume it is okay.

> 2) Please break up the calculations in DoSnapGrid into multiple
>lines unsing temp variable.  It's too hard to read = hard to
>maintain.  The previous un-readability of the code shouldn't be
>the standard we aim at.  ;-)

I tried to clean this up a bit, was mostly just cutting/pasting code.

> 3) Same for "smap_mon = ...".  Ouch.

Agreed, tried to simplify it a bit.

> 4) I'm not sure whether screen boundaries should have a higher
>priority than windows and not equal priorities.  That would
>require scoring.
>
>Shouldn't be too difficult to implement; the new sub functions
>would simply return a score = the absolute snapping distance
>that was used, and the lowest one wins.  (Gird is still only
>used if there was no other snapping.)
>

Returning a single score won't work, since vertical and horizontal are
treated separately.

Instead I now find both an appropriate monitor edge and window edge.
Then snap to the closest. If none is found, fallback to using the
grid.

> 5) Edge resistance is a kind of reverse snapping with a different
>snap distance:  A window that has been moved past the screen
>edge "snaps" back until it has moved more than the edge
>resistance past the edge.  This is exactly what snapattraction
>does, just with the snap distance from a different variable.
>
>Can that be merged with the new code?

This ended up being a bit more complicated, since the resistance isn't
the same as snap attraction (since snap attraction snaps both
left/right but resistance is only one direction). But I was able to
update the monitor function to be able to now deal with both snapping
and resistance by passing it a few bools to control its behavior. I
also took advantage of the new info about if a monitor edge is an
outside or inside edge to distinguish resistance between monitors and
between pages. Though the code is a bit more complicated, I hope it is
readable.

On Sat, Nov 20, 2021 at 9:45 PM Dominik Vogt  wrote:
>
> And there's still a bug that had been present in the old code:
>
> I.e. the top/left/right/bottom border of a window shouldn't snap
> to the bottom/right/left/top border of a windows if that latter is
> aligned with a screen edge.
>

I have added a final check in DoSnapWindow that ignores snapping to
windows on the monitor edge. I think this fixes the issue.

All of the updates have been pushed to js/snapattract.

jaimos

Re: git access

[Jaimos Skriletz]

On Sat, Nov 20, 2021 at 10:17 PM Dominik Vogt  wrote:
>
> Sending patches is getting out of hand.  I believe I had once
> write access to the git repo, but it doesn't work anymore
> (permission denied when updating).  What do I need to do to
> reactivate access?
>

If you were using a password to access github, that is no longer
allowed from the command line. You need to create a personal access
token to use. Or an ssh key.

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token

Re: Snapping issue

[Jaimos Skriletz]

On Sun, Nov 14, 2021 at 10:57 AM Dominik Vogt  wrote:
>
> The snapping code is really an unmaintainable mess.  Some thoughts
> on how it might be rewritten:
>

Here are some thoughts I have, you can see them in js/snapattract branch.

I have split the three different snapping checks into individual
functions for Monitor Edges, Windows, and Grid. I have then set up a
priority of Monitor > Windows > Grid, so this way when something is
found to snap too, it stops looking for other things based on the
priority, and this should stop some of the strange interactions
between deciding what to snap too. I also treat horizontal and
vertical independently so it can snap to both a window and a monitor
edge in different directions. Currently the priority is hardcoded, but
since the checks are now individual functions, it could be possible to
set it up so the user can configure what snap priority. Comments
welcome.

jaimos

Re: [PATCH] (6) Man page changes -- second attempt

[Jaimos Skriletz]

On Wed, Nov 17, 2021 at 11:20 AM Thomas Adam  wrote:
>
> On Wed, Nov 17, 2021 at 02:35:32PM +0100, Dominik Vogt wrote:
> > On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote:
> > > This is the full set of patches for splitting the man page, to be
> > > applied to master.
> >
> > Second attempt.  The style docs are not moved aound in the man
> > page.  The .section files have been renamed to .ad because
> > asciidoc only evaluates "ifdef" in included files if they have a
> > known extesion.  ".adoc" cannot be used because the pattern rules
> > in the Makefile.am would conflict.
> >
> > The patch stack has been reshuffled and patches have heen merged,
> > and two new ones on top have been added.
>
> Thanks, Dominik.  This applies cleanly now.  I've also added an OVERVIEW
> section to fvwm3all.adoc explaining how the man page is split up into
> different sections.
>
> I'm going to merge this to master, albeit I'm hoping to create some additional
> sections as well so it doesn't feel like this change is incomplete.
>

Lintian found a few minor typos in the manual pages. Patch attached.

jaimos
diff --git a/doc/fvwm3_manpage_source.adoc b/doc/fvwm3_manpage_source.adoc
index d78b5d22..48f3d3b7 100644
--- a/doc/fvwm3_manpage_source.adoc
+++ b/doc/fvwm3_manpage_source.adoc
@@ -26,7 +26,7 @@ large, and you can scroll around within the desktop.  The multiple
 disjoint desktops pretend there are really several screens to work
 at, but each screen is completely unrelated to the others.
 
-Fvwm provides _keyboard accelerators_ that allow to perform practically
+Fvwm provides _keyboard accelerators_ that allow one to perform practically
 all window manager functions, including moving and resizing windows and
 operating the menus, using keyboard shortcuts.
 
@@ -2493,7 +2493,7 @@ AddToMenu RootMenu
 
 Menu styles describe the looks and behaviour like normal styles do
 for windows. Menu styles are assigned to individual or all menus,
-and changing the menu style immediately affects all menus taht use
+and changing the menu style immediately affects all menus that use
 it.  (If a menu style is used from within a menu, the changes are
 applied the next time an affected menu is opened.)
 
@@ -4012,7 +4012,7 @@ style.  Moving a window to the edge of the screen can be used to drag the
 window to other pages.  (See *EdgeScroll*, and the _EdgeMoveDelay_ style for
 more information.)
 +
-Holding down _Alt_ disables snapping and allows to switch pages
+Holding down _Alt_ disables snapping and allows one to switch pages
 without any delay.  Interactive movement can be aborted with the
 _Escape_ key or any mouse button not set to place the window. By default mouse
 button 2 is set to cancel the move operation. To change this you may

Re: Some advices about the new static website

[Jaimos Skriletz]

On Fri, Apr 8, 2016 at 4:40 PM, Thomas Funk  wrote:

> I'm not clear what you're referring to with "linking" either.
>>
>
> I meant the links in
> http://fvwm.org/doc/unstable/fvwm/fvwm.man.html
>
> And again the html docs under http://fvwm.org/doc/unstable are/were the
> same as under http://fvwm.org/doc/stable since ages.
>
>
​I believe I know which ones you were talking about.​

​Was this the alphabetical ​list of terms that linked to their location
inside the man pages. It was a nice set of links as it made looking for
some things easier.

​Right now the only links are at the bottom of each manpage (with a link
from the top) or just searching the man page for key words. (I guess for
the time I could take the links at the bottom of each manpage put them
nicely located at ​http://fvwm.org/documentation/manpages/) as this is a
copy paste, but I don't think these are the links you were talking about).

It may be nice to get something like that back up, but with the conversion
of the manpages to markdown the current scripts will be outdated, so after
that conversion is done, I will go checkout how to get such a set of links
setup. Provided they only linked to headings that will be generated by
markdown this should be fairly straight forward to script.

jaimos

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Jaimos Skriletz]

On Mon, Apr 4, 2016 at 11:31 AM, Jason L Tibbitts III <ti...@math.uh.edu>
wrote:

> >>>>> "JS" == Jaimos Skriletz <jaimosskril...@boisestate.edu> writes:
>
> JS> So to complete the switch the fvwm.org domain needs to be pointed
> JS> at/redirected to github.io.
>
> That's easy for me to do, but before I make any changes.
>
> JS> I think pointing fvwm.org at github would be preferable as to keep
> JS> the domain name, but I'm unsure of anything that would need to be
> JS> done on github.io end to accept the fvwm.org as a virtual host and
> JS> point it to the correct location.
>
> Could someone triple check on that?
>
>
​Here is the documentation:

​​
https://help.github.com/articles/using-a-custom-domain-with-github-pages/
https://help.github.com/articles/setting-up-your-pages-site-repository/

​From the DNS end you just need to set up the appropriate A, ANAME, ALIAS
record in the DNS.

>From Git repo end there needs to be a single file CNAME with the contents `
fvwm.org` as a single line in that file added to the fvwmorg.gethub.io
source. I will add this later tonight when I get home (and test it works)
before you need to update the DNS.

So it seems easy enough. Only thing It is not clear about what ip to point
at. I would assume the ip that fvwmorg.gethub.io is pointing at.

jaimos

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Jaimos Skriletz]

On Fri, Apr 1, 2016 at 5:43 PM, Thomas Adam <tho...@fvwm.org> wrote:

> On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> > ​​
>
> Thanks!  It looks really good.  We can remove the Changelog section; people
> can look at the release descriptions and/or Git history from now on.
> Maintaining this is a doubling of effort for absolutely no reason.
>
>
​The ChangeLog page is just links to the files on GitHub so there is no
maintenance on the page. Could be removed, I just thought it would be nice
to have links easily found on fvwm.org for them.
​


> In terms of the FAQ, have you (for now) just copied that from
> $FVWM.GIT/docs/
> ?  If so, I can remove that file from the FVWM repo and make the one in
> fvwmorg.gh.io the authoritative version (as it should be).  Same goes for
> removing other files from the FVWM repo too, but that's a different
> concern.
>
>
No, the FAQ is a html dump (save as) from the old fvwm.org page as it was a
copy of that file with linked anchors in it. The FAQ needs to be converted
into a markdown file (complete with anchored links). Then I will create a
simple wrapper to wrap the markdown file into the webpage. I would keep the
FAQ around in $FVWM.GIT/docs/ until then.

Also I am unsure if these various markdown files, FAQ.md, AUTHORS.md,
DEVELOPERS.md, etc should be located and maintained on the webpage or
in $FVWM.GIT source. I think either can work with git.io so it is probably
a matter of preference. But agreed, these markdown files should all be
collected and maintained in a single place.



> > I am working on a 'Config' section for the site to include examples of
> > decors, icons, sounds and vector buttons (many adapted from fvwm-themes).
> > But this is gonna take a while as I play with the different decors.
>
> Maybe.  It might be easier to just direct people towards things like
> Fvwm-{Crystal,Nightshade}.  The icons/sounds/etc., can just be forgotten
> about.  They're so old, it's not even funny, and if someone *really* wants
> those, shove them on the wiki.


​Agreed on the age of the resources. It may be that fvwm.org doesn't
provide any actual resources for configs and just points to other sites and
what I have been collecting can be put elsewhere. My vision wasn't to be a
full
configuration like Crystal or Nightshade, but provide configuration
examples complete with any resources needed (images, etc). ​My rough idea
was to include

   - A simple/minimal "default" config.
   - Examples of various config snippets for things such as Vector
   Buttons, Window Decors, Menus, Modules, etc. (This was kinda attempted on
   the current fvwm.org page).

I think the actual question is should fvwm.org provide any resources for
configurations like above, or should it only link to other sites? This is
also not something I was planning on including in the initial transition of
moving the site to git.io, but was something I was thinking of developing
and adding if there was interest to have a collection of config snippets on
fvwm.org. If not I will look into updating the wiki (though I am liking
jekyll over ikiwiki for building static pages).



> > I also think adding some feature to the buttons on the page would be
> nice,
> > but not sure what sort of silly feature (maybe some js/css magic) would
> be
> > good to add to the site.
>
> Maximizing of the div, perhaps?
>
> > Anyways, those are some ideas but as of now the above links give a
> > recreation of fvwm.org using a static site (with some redesigning). Any
> > input is appreciated.
>
> Thanks for this, Jaimos.  One question:  how would we handle adding new
> screenshots?  There's a script which runs to generate some HTML.  I presume
> this is manual at the moment?
>
>
​Currently it is a script which needs to be run manually (same for the man
pages, and that script is in worse shape, has hard links to files in my
$HOME). Once the site is on git.io I was thinking of looking into what sort
of hooks there are to generate stuff during the generation. Its current
state is just to be static for the move.
​
My hope is I got the site to a place that it can be transferred over to
git.io as a static page. Most of the above are things that can be resolved
after the transfer. This also includes adding any new content/features to
the site.

​jaimos​

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Jaimos Skriletz]

​​

On Sat, Mar 26, 2016 at 2:09 PM, Jaimos Skriletz <
jaimosskril...@boisestate.edu> wrote:

> Here is what I have created so far
>
> http://fvwmforums.org/fvwm.org/
>
> The sources are available on github
>
> https://github.com/somiaj/fvwmorg.github.io
>
>
​Update: ​The site is mostly complete and can probably be used as is. Just
seeing if there is anything that should be added or removed from the site
(you can check out the copy on fvwmforums.org for the current site).

I am working on a 'Config' section for the site to include examples of
decors, icons, sounds and vector buttons (many adapted from fvwm-themes).
But this is gonna take a while as I play with the different decors.

I also think adding some feature to the buttons on the page would be nice,
but not sure what sort of silly feature (maybe some js/css magic) would be
good to add to the site.

Anyways, those are some ideas but as of now the above links give a
recreation of fvwm.org using a static site (with some redesigning). Any
input is appreciated.

jaimos​

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Jaimos Skriletz]

Here is what I have created so far

http://fvwmforums.org/fvwm.org/

​Jekyll seems to be fairly straight forward for the basics. Once the
framework is setup, you can just add/remove files as either .html or
.markdown (.md) with a small YAML header. This will then cause the software
to generate the static website by wrapping each html or markdown page into
the layout.​

I tried to keep to the base theme and just be simple. From here it is
mostly a matter of filling in all the missing pages.

The link above is to get some feedback on design. Also let me know of any
additional features you think should be added/removed.

The sources are available on github

https://github.com/somiaj/fvwmorg.github.io

jaimos

Re: FVWM website: WAS: [Re: FVWM code moved to Github]

[Jaimos Skriletz]

>
> Jaimos Skriletz has also expressed an interest in this (I'ev Cced him), and
> he'll post here soon about what his thoughts are, etc.  Hopefully you and
> he
> can work together on this.
>

​Hello, I have offered to help migrate the fvwm.org to something more
maintainable as this is something Thomas was wanting help with in #fvwm.

I am unsure on a lot of the details about how the current site is
generated, who controls the domain name fvwm.org, and what any current or
future plans for the site are, but offered to help in any migration.

Thomas mentioned wanting to move it to git-hub and generating it from
markdown using jekyll. So I offered to learn jekyll and convert the current
site to a static site written in markdown. I was just going to do this all
locally and see what I am able to get done in figuring out how to customize
a site with jekyll.

So this email is just to let you know that I'm looking at what it would
take to move the site to markdown and use jekyll to generate a static copy.
I'm thinking once I get it configured a lot of copying and pasting, but
I'll have to get back to the jekyll docs to figure out more.

jaimos