Re: Crashes with monitor_resolve_name

[Thomas Adam]

On Sat, Nov 27, 2021 at 07:02:29PM +0100, Dominik Vogt wrote:
> Are there other places with unusual monitor name parsing?

Maybe in GotoDeskAndPage, but I don't think there's other places.

-- Thomas

Re: [RFC] Fix window title format leak?

[Thomas Adam]

On Fri, Nov 26, 2021 at 01:17:42AM +0100, Dominik Vogt wrote:
> Is this the proper fix?

I think so.  I can't see it leak under Valgrind...

Kindly,
Thomas

Re: memleak in FScreenParseGeometryWithScreen

[Thomas Adam]

On Fri, Nov 26, 2021 at 12:45:36AM +0100, Dominik Vogt wrote:
> On Thu, Nov 25, 2021 at 11:04:25PM +0000, Thomas Adam wrote:
> > On Wed, Nov 24, 2021 at 03:13:34PM +0100, Dominik Vogt wrote:
> > > From FScreen.c:FScreenParseGeometryWithScreen():
> > >
> > > I can't fix this because I don't understand what the code does.
> >
> > I will fix this.
> 
> Too late, but please do look at the two commits I made.  The

I'll check more thoroughly in the morning.  I'm not too sure this should have
been merged to master though as it's still under review, as far as I can tell.
There's no need to rush to merge on-going work like this.

> structure "icon_boxes" (fvwm.h) really should not contain an
> allocated string.  Can we not store the numeric screen rectangle
> instead of the name?

Quite possibly.  I've a few other fixes to IconBox laying around here, so I'll
double-check.

Kindly,
Thomas

Re: memleak in FScreenParseGeometryWithScreen

[Thomas Adam]

On Wed, Nov 24, 2021 at 03:13:34PM +0100, Dominik Vogt wrote:
> From FScreen.c:FScreenParseGeometryWithScreen():
>
> I can't fix this because I don't understand what the code does.

I will fix this.

Kindly,
Thomas

Re: UPDATE_FVWM_SCREEN macro?

[Thomas Adam]

On Wed, Nov 24, 2021 at 03:43:47PM +0100, Dominik Vogt wrote:
> Does anybody know why this is a macro and not a function?
> (screen.h)

Because when I wrote it, it wasn't as complex as it is now.

See the ta/update-fvwm-screen branch, I've converted it to a function instead.

Kindly,
Thomas

Re: [PATCH/RFC] Xinerama

[Thomas Adam]

On Tue, Nov 23, 2021 at 12:31:15AM +0100, Dominik Vogt wrote:
> The old manmage said:
> 
>   XineramaRoot
> 
>   the root window of the whole Xinerama screen.  Equivalent to
>   "root" when Xinerama is not used.
> 
> Can you please restate that for me?  What is "whole Xinerama
> screen" in xrandr terms?

>From a quick scan of the code in menus.c where xineramaroot is being used,
it's not entirely clear to me, but if this option is meant to do what I think
it is, then this would be taking the width/height of the monitor the
pointer/window is on, rather than referencing the width/height of the entire
root window.

Kindly,
Thomas

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Mon, Nov 22, 2021 at 11:26:14PM +0100, Dominik Vogt wrote:
> I want to remove completely it once the code has been tested well
> enough.  It's just there for the moment in case something happens.

OK.  I'm now about to merge this to master.

Thanks,
Thomas

Re: [PATCH/RFC] Xinerama

[Thomas Adam]

On Mon, Nov 22, 2021 at 11:26:53PM +0100, Dominik Vogt wrote:
> On Sun, Nov 21, 2021 at 12:39:07AM +0100, Dominik Vogt wrote:
> > Patch attached.  Can you please double check and fill in the gaps?
> > (see comments belo).
> >
> > > > ./fvwm/menus.c: fXineramaRoot = False;
> > > > ./fvwm/menus.c:   else if (StrEquals(tok,"xineramaroot"))
> >
> >
> > Not sure what the right name of the option and the flag variable
> > should be.  There's only a placeholder in the man page either.

Making that change would be syntactically breaking people's configs, but... I
bet it's a rarely-used option that should just be "screenroot" or something.

> > > > ./perllib/FVWM/Commands.pm: descr => q{Move a window to 
> > > > another Xinerama screen},
> >
> > [MOVE_TO_SCREEN]
> > This one should be just renamed to just "screen"?

Yes please.

> Ping.

Sorry, I didn't spot this earlier.

Kindly,
Thomas

Re: [RFC] Fake a global monitor when RanfR is not available.

[Thomas Adam]

On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote:
> For debugging I need to run another fvwm in xnest, but that
> doesn't support randr.

Bloody xnest/xephyr.

I suppose this OK, but it bothers me we need to fix it this way... I am not
sure though there's a workaround.

> The attached patch mocks up a global monitor to use if init fails.
> It works at the first glance, but the patch is not very clean.
> Please comment.

It sucks.  Under whar circumstances is this likely to fail?  I mean, I
appreciate the point you're making, but whatelse am I missing?

Kindly,
Thomas

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Mon, Nov 22, 2021 at 12:02:33AM +0100, Dominik Vogt wrote:
> Mostly done, except a couple of comments where there's still work
> to do.

OK, I'll wait for those.

I've not noticed any crashes from running this for three days now.

Note that I still don't think we should hide the debugging behind
'#define OCP_DEBUG 1' even though it's always set to on at compile time.
Certainly not for new code.  We could make it a BugOpts option if it really
mattered.  I'm not saying we need to fix this now, mind you.

Kindly,
Thomas

Re: Idea: "elastic" move

[Thomas Adam]

On Mon, Nov 22, 2021 at 12:24:09AM +0100, Dominik Vogt wrote:
> Yes, when the pointer comes too close to any border (leaves the
> dotted area on the sketch), it's warped back by the __move_loop to
> the original "P" in the sketch.  Thus it can continue moving in
> all directions.  Of course, the window does not follow the warp.
> The (P)ointer to (W)indow offset is internally adjusted to a new
> value.

Ah, yes of course.  This makes sense now.  Thanks.  I guess there could be
more movement with the mouse than before, but we'll have to see what it's
like.

Incidentally, isn't this sort of concept what FvwmProxy was trying to do?  I
seem to recall you could simultaneously move multiple windows...

Kindly,
Thomas

Re: Idea: "elastic" move

[Thomas Adam]

On Sun, Nov 21, 2021 at 03:29:29PM +0100, Dominik Vogt wrote:
> Situation:  At the moment, interactive move with the mouse feels
> awkward.  Pushing windows past the page edge often fails because
> the pointer hits the edge and cannot move further.  It's annoying
> and uncomfortable.  The "pointer hits page border" this is a real
> show stopper.

Yeah, that all makes sense.

> 1. When an interactive move starts:
> 
> - Replace the pointer with an invisible one.
> - Warp the pointer to the middle of the screen.  There it can
>   always be moved in all directions.
> - If the pointer gets too close to the page edges, warp it back
>   to the middle of the screen.
> - At the end of the move, warp it back to the original
>   position relative to the window.
>(- Maybe a fake cursor can be drawn at the original position so
>   that the user does not get confused.)

So... if I understand this correctly, you would have something like this:

   +--+ 

   |S | 

   |  | 

   |  | 

   |  | 

   |  | 

   |  | 

   |  | 

   |  | 

   |  | 

   |P | 

   |  | 

   |  | 

   |  | 

   |  ++  | 

   |  ||  | 

   |  ||  | 

   |  ||  | 

   |  |   W|  | 

   |  ||  | 

   |  ||  | 

   |  ++  | 

   |  | 

   +--+ 
 


If I'm moving window W interactively, pointer (P) is moved to the middle of
the screen, if I move it right, the window follows that -- but at the distance
of the window's top border and where the pointer is, presumably?

What if I want to have window W moved to the top-right of the screen (S)?
Wouldn't my pointer end up being at the top of the screen before the window
could reach it, and hence the pointer would be warped back to the middle of
screen S?

> 2. Remove timed paging during interactive move completely
>(EdgeMoveDelay style)

Yes please.

> 3. Instead, when you push the original pointer position off page
>the viewport automatically starts scrolling to keep that
>position (the fake pointer) visible.
> 
>Think of the current viewport position being connected with the
>original one with a rubber band:  If you change you mind and
>move the window back towards its original position, the viewport
>also moves back, relaxing the rubber band.

I think I can visualise this in my mind -- and I think it makes sense as
moving a window is a conscious choice in that a user's going to know where it
started, and so treating its moving like an elastic band could work.

> 4. When the move ends, the window is placed and the viewport snaps
>back to a full page.  It may be a bit tricky to choose the
>proper page automatically.  It's easy if the window has
>completely moved to another page, but what if it's stuck between
>two or even four pages?

This concept between pages and viewing many different parts of the overall
virtual desktop has always meant situations like this happen even now.  I
don't have a good answer to this.

We also need to think about:

* How FvwmPager is going to react to this -- I think it will handle the
  scrolling nature just fine, but there's still a chance it might get
  confused.
* Edge-sensitivity to 'DesktopConfiguration per-monitor' and screen boundaries
  

Re: [RFC] parser branches ready for commit

[Thomas Adam]

On Sun, Nov 21, 2021 at 02:38:09PM +0100, Dominik Vogt wrote:
> The parser branch is a ready as it will be without people testing
> it more.  The upstream branch dv/master hat the latest, merged
> together patches with extensive debug to stderr enabled.
> 
> Please take a look.  If there are no findings I'd like to put this
> on master.

I'll keep testing it here over the next few days.  

Before merging, it would be nice to:

* Convert some/all of the printf(stderr, ...) calls to fvwm_debug() lines so
  debugging is going through that mechanism.  I know historically we've had
  different sections for certain debug (stack-ring, enternotify debug, etc.)
  but I am trying to move away from that, and if you turn on debugging, you
  get everything.  This has helped supporting users already last year, in my
  experience.
* Remove/convert some remaining comments starting "!!!".
* Decide on the '#if 1' blocks -- are there they to stay permanently? 
* Not just related to change per se (but still present) appears to be what I
  would class as extraneous "return;" lines at the end of void functions which
  seems odd to me.

I will also get some tests in place as well.

> (Note: Produces a ton of debug output and is not suitable to the
> general audience.  Debug output can be disabled by debug defines
> in functions.c and cmdparser_old.c.)

It's things like this which tell me "it's not quite ready yet to be merged".
Which is good, because this branch is level with master so it doesn't need to
be merged just to test it -- and it's that shift in mentality, trying to
keep master in the most stable state it can be which helps a lot with the
release process.

Kindly,
Thomas

Re: dv Branches

[Thomas Adam]

On Sun, Nov 21, 2021, 11:22 Dominik Vogt  wrote:

> Okay, git access works again.  I'll do further development on
> dv/devel or on private topic branches, then put them in dv/master
> before considering to push them.
>

That's one way of doing it, yes. Whichever is going to make it easier for
you, and also for reviewing.

This is why I don't want an upstream branch. Merging topics into master can
accumulate there for the next release. The review process of those topics
makes things easier to manage.

I'm out for the rest of the day but will be back later.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sun, Nov 21, 2021 at 11:41:33AM +0100, Dominik Vogt wrote:
> "git add -i" is extremely useful for not accidentally committing

It's "git add -pi" which I use all the time.

However, this is more about me hunting down which plugin is causing this and
turning it off.

Kindly,
Thomas

Re: git access

[Thomas Adam]

On Sun, Nov 21, 2021 at 12:59:17AM +0100, Dominik Vogt wrote:
> Sending patches is getting out of hand.  I believe I had once

Ah.  I had thought you were doing this because you preferred this way of
working.

> 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?

You're a member of fvwmorg on github -- so presumably the permission denied
you're seeing is an out of date SSH key?

> (A quick recap of the procedure involved in getting patches on
> master wold help too.  I'd also be happy with my own branches
> without committing to master myself.)

See:  https://github.com/fvwmorg/fvwm3/blob/master/dev-docs/DEVELOPERS.md

Kindly,
Thomas

Re: fork-bomb like functions

[Thomas Adam]

On Sun, Nov 21, 2021 at 12:51:46AM +0100, Dominik Vogt wrote:
> How about
> 
>  1. MAX_FUNCTION_DEPTH100  (stricter limit)
>  2. MAX_FUNCTION ITEMS   1000  (limit maximum size of functions)
>  3. MAX_CMDS_PER_INVOCATION 1  (max. cmds per top level function 
> invocation)

Sounds sensible to me.  I say, go for it!

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:16:02PM +0100, Dominik Vogt wrote:
> Look at commit ba9f161998f7da942996bcf0d3f96baa8b249070.  You
> added new-parser.md, but also committed a complete reindentation
> of functions.c.

Oh heavens.  That's not good at all.  Clearly something has run in the
background and I had not even noticed at the point I commited that change as I
was in no way expecting anything other than that markdown file to have
changed.  That's why I didn't even check.

Sorry about that.  I'll have to check to see how that happened.  There's a
possibility some "helpful" vim plugin has done this, although it hasn't done
so in the past.

Kindly,
Thomas

Re: fork-bomb like functions

[Thomas Adam]

On Sat, Nov 20, 2021 at 04:26:13PM +0100, Dominik Vogt wrote:
> I wonder if we should do something about these kind of functions:
> Theres the definition "MAX_FUNCTION_DEPTH 512" in defaults.h that
> prevents functions from nesting infinitely deep:

Yeah.  How likely is this problem in the real world though?  As in, how many
people have actually done this?  I can't say I've ever had to support a user
who has managed to get into this situation.

Even then, what's wrong in just keeping it as it is?

> I could add an execution counter that limits the total number of
> command lines that can be executed from a single top level
> function call; maybe limit that to 1000.

Maybe, if this is an actual problem...

> Another problem:  It's possible to add items to functions that are
> currently in use.
> 
>   addtofunc foo i bar
>   addtofunc bar i addtofunc foo i bar
>   # hangs:
>   foo

I can maybe foresee this situation arising.  Maybe this is worth fixing?

Kindly,
Thomas

Re: Xinerama

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> On Sat, Nov 20, 2021 at 02:15:58PM +0000, Thomas Adam wrote:
> > On Sat, Nov 20, 2021, 14:13 Dominik Vogt  wrote:
> >
> > > Is Xinerama still useful for anything or can we remove it?
> > >
> > It has already been removed. Where are you seeing references to it?
> 
> Everywhere.  I'll remove the junk on the parser branch.
> 
>  $ rgrep -i xinerama . 2> /dev/null
> ./libs/defaults.h:/*** Xinerama ***/
> ./libs/defaults.h:#define DEFAULT_XINERAMA_ENABLEDTrue /* Xinerama on 
> by default */
> ./libs/defaults.h:#define XINERAMA_CONFIG_STRING "XineramaConfig"

These can go, and the corresponding callers in FvwmForm can be changed.  This
looks to be the mechanism module used to use to register Xinerama interest.

> ./libs/FTips.c:   fscreen_scr_arg *fsarg = NULL; /* for now no xinerama 
> support */

That comment is misleading and can be changed,

> ./modules/FvwmForm/FvwmForm.c:  if (strncasecmp(buf, XINERAMA_CONFIG_STRING,
> ./modules/FvwmForm/FvwmForm.c:  
> sizeof(XINERAMA_CONFIG_STRING)-1) == 0)
> ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + 
> sizeof(XINERAMA_CONFIG_STRING)-1);
> ./modules/FvwmForm/FvwmForm.c:buf, XINERAMA_CONFIG_STRING, 
> sizeof(XINERAMA_CONFIG_STRING)-1)
> ./modules/FvwmForm/FvwmForm.c:FScreenConfigureModule(buf + 
> sizeof(XINERAMA_CONFIG_STRING)-1);

See above.

> ./modules/FvwmButtons/FvwmButtons.h:void handle_xinerama_string(char *args);

That's just a function declaration without an implementation and can be
removed.

> ./.git/rr-cache/1c03ad931074cd97196af43ae2fc0134a13171cd/preimage:directly 
> adjacent to the screen's or xinerama screen's border. It
> ./.git/rr-cache/d3fcccba50db8b879e64033b3c5f2ebe88fa6f57/preimage:directly 
> adjacent to the screen's or xinerama screen's border. It

rerere cache from git so will ignore.

> ./doc/fvwm3_commands.ad:directly adjacent to the screen's or xinerama 
> screen's border. It
> ./doc/fvwm3all.1:directly adjacent to the screen\(cqs or xinerama screen\(cqs 
> border. It
> ./doc/fvwm3_styles.ad:directly adjacent to the screen's or xinerama screen's 
> border. It
> ./doc/fvwm3styles.1:directly adjacent to the screen\(cqs or xinerama 
> screen\(cqs border. It
> ./doc/fvwm3_manpage_source.adoc:directly adjacent to the screen's or xinerama 
> screen's border. It

These can change to either mention RandR, or just "screen".

> ./fvwm/windowlist.c:   * because it sets the xinerama screen origin */
> ./fvwm/add_window.c:  fw->edge_resistance_xinerama_move =
> ./fvwm/add_window.c:  pstyle->edge_resistance_xinerama_move;
> ./fvwm/move_resize.c:  * in case Xinerama is used. */
> ./fvwm/move_resize.c: /* Resist moving windows between xineramascreens */
> ./fvwm/move_resize.c: if (fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: scr_x1 + fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: scr_y1 + fw->edge_resistance_xinerama_move)
> ./fvwm/move_resize.c: fw->edge_resistance_xinerama_move)


Funtionally now referencing RandR and are poorly named as xinerama isn't used.

> ./fvwm/style.c:   if (add_style->flags.has_edge_resistance_xinerama_move)
> ./fvwm/style.c:   SSET_EDGE_RESISTANCE_XINERAMA_MOVE(
> ./fvwm/style.c:   
> SGET_EDGE_RESISTANCE_XINERAMA_MOVE(*add_style));
> ./fvwm/style.c:   unsigned has_xinerama_move;
> ./fvwm/style.c:   has_xinerama_move = 0;
> ./fvwm/style.c:   has_xinerama_move = 1;
> ./fvwm/style.c:   has_xinerama_move = 0;
> ./fvwm/style.c:   
> ps->flags.has_edge_resistance_xinerama_move =
> ./fvwm/style.c:   has_xinerama_move;
> ./fvwm/style.c:   
> ps->flag_mask.has_edge_resistance_xinerama_move = 1;
> ./fvwm/style.c:   
> ps->change_mask.has_edge_resistance_xinerama_move = 1;
> ./fvwm/style.c:   SSET_EDGE_RESISTANCE_XINERAMA_MOVE(*ps, 
> val[1]);
> ./fvwm/fvwm.h:char*IconScreen;   /* Xinerama 
> screen */
> ./fvwm/fvwm.h:unsigned has_edge_resistance_xinerama_move : 1;
> ./fvwm/fvwm.h:int edge_resistance_xinerama_move;
> ./fvwm/fvwm.h:int edge_resistance_xinerama_move;

As above.  This just needs renaming.

> ./fvwm/commands.h:F_XINERAMA,
> ./fvwm/commands.h:F_XINERAMAPRIMARYSCREEN,
> ./fvwm/commands.h:F_XINERAMASLS,
> ./fvwm/co

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 10:51:51AM +0100, Dominik Vogt wrote:
> It works on my local branch but not the one in Git because of the
> reindentation commit.  Can we please not reindent patches that are
> still under development?

I haven't reindented anything -- at least, not knowingly.  Even then, how did
that cause the failure in the first place?

> I'll ditch the upstream branch for now and start a new one.

Well, new-parser builds fine now, thanks.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> > On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> > > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > > > > A couple of patches for the parser branch:
> > > > >
> > > > > 0001: Some cleanup.
> > > > > 0003: Fix function depth handling and an uninitialised function 
> > > > > argument.
> > > > >   (I.e. a crash)
> > > >
> > > > Thanks; applied these two.
> > >
> > > You'll need to fix some missing #includes though, as the build's failing, 
> > > but
> > 
> > Builds fine with gcc-10.2.1 in a clean source tree with
> > 
> >   $ make CFLAGS="-g3 -O3 -Wall -Werror" -j 4
> > 
> > Can you give me the error messages that cause it?
> 
> See fvwm.log attached.  It's possible I've missed a patch, but the code
> corresponding to this build is on the new-parser branch in git, FYI.
> 
> I know I'm being lazy, I could fix this myself, but I'd like you to check,
> just in case there's something else missing which you're working on at the
> same time...

This works, but I am confused as to why it compiles fine for you:

diff --git a/fvwm/cmdparser_hooks.h b/fvwm/cmdparser_hooks.h
index 42330246b..d8ebde017 100644
--- a/fvwm/cmdparser_hooks.h
+++ b/fvwm/cmdparser_hooks.h
@@ -3,6 +3,9 @@
 #ifndef FVWM_CMDPARSER_HOOKS_H
 #define FVWM_CMDPARSER_HOOKS_H
 
+#include "cmdparser.h"
+#include "functions.h"
+
 /*  included header files -- */
 
 /*  global definitions - */

Kindly,
Thomas

Re: [PATCH] (6) Various small changes

[Thomas Adam]

On Sat, Nov 20, 2021 at 03:03:44AM +0100, Dominik Vogt wrote:
> For master:
> 
> 0001: Fix uninitialised variables in lib.
> 0002: Remove "-blackout" option.
> 0003: Docuement -v and alias it to --verbose.
> 0004: Don't list all options in the SYNOPSIS.
> 0005: Change getpwuid.c interface (for next patch)
> 0006: Implement -o/--output-logfile option.
>   If given, use that logfile (abs or relative path)
>   If the path is just "-", use stderr
>   If not present use file from env variable
>   If not presen, use default.
> 
> fvwm -v -o - ...   # to stderr
> fvwm -v -o //home/foo/bar  # to file
> 
>   The patch also fixes a memory leak.

Makes sense.  Applied, with a few tweaks.

Note that the use of stderr is going to be interesting.  Unless you've
explicitly captured stderr beforehand, some display managers won't capture
stderr which is why I didn't previously include it, but then again if you're
still starting fvwm via .xsession or .xinitrc, this will be useful.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Sat, Nov 20, 2021 at 12:23:26AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 03:15:43PM +0000, Thomas Adam wrote:
> > On Fri, Nov 19, 2021 at 03:09:35PM +0000, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > > > A couple of patches for the parser branch:
> > > >
> > > > 0001: Some cleanup.
> > > > 0003: Fix function depth handling and an uninitialised function 
> > > > argument.
> > > >   (I.e. a crash)
> > >
> > > Thanks; applied these two.
> >
> > You'll need to fix some missing #includes though, as the build's failing, 
> > but
> 
> Builds fine with gcc-10.2.1 in a clean source tree with
> 
>   $ make CFLAGS="-g3 -O3 -Wall -Werror" -j 4
> 
> Can you give me the error messages that cause it?

See fvwm.log attached.  It's possible I've missed a patch, but the code
corresponding to this build is on the new-parser branch in git, FYI.

I know I'm being lazy, I could fix this myself, but I'd like you to check,
just in case there's something else missing which you're working on at the
same time...

Kindly,
Thomas
 /bin/sh ./config.status
config.status: creating Makefile
config.status: creating libs/Makefile
config.status: creating fvwm/Makefile
config.status: creating modules/Makefile
config.status: creating bin/Makefile
config.status: creating bin/FvwmCommand
config.status: creating bin/FvwmPrompt/Makefile
config.status: creating bin/fvwm-config
config.status: creating bin/fvwm-perllib
config.status: creating bin/fvwm-menu-xlock
config.status: creating bin/fvwm-menu-directory
config.status: creating bin/fvwm-menu-desktop
config.status: creating bin/fvwm-convert-2.6
config.status: creating utils/Makefile
config.status: creating perllib/Makefile
config.status: creating perllib/General/Makefile
config.status: creating perllib/FVWM/Makefile
config.status: creating perllib/FVWM/Module/Makefile
config.status: creating perllib/FVWM/Tracker/Makefile
config.status: creating perllib/FVWM/Module.pm
config.status: creating default-config/Makefile
config.status: creating doc/Makefile
config.status: creating po/Makefile
config.status: creating modules/FvwmAnimate/Makefile
config.status: creating modules/FvwmAuto/Makefile
config.status: creating modules/FvwmBacker/Makefile
config.status: creating modules/FvwmButtons/Makefile
config.status: creating modules/FvwmConsole/Makefile
config.status: creating modules/FvwmEvent/Makefile
config.status: creating modules/FvwmForm/Makefile
config.status: creating modules/FvwmIconMan/Makefile
config.status: creating modules/FvwmIdent/Makefile
config.status: creating modules/FvwmMFL/Makefile
config.status: creating modules/FvwmPager/Makefile
config.status: creating modules/FvwmPerl/Makefile
config.status: creating modules/FvwmPerl/FvwmPerl
config.status: creating modules/FvwmRearrange/Makefile
config.status: creating modules/FvwmScript/Makefile
config.status: creating modules/FvwmScript/Scripts/Makefile
config.status: creating modules/FvwmScript/Widgets/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
make  all-recursive
make[1]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3'
Making all in default-config
make[2]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3/default-config'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/home/n6tadam/projects/fvwm/fvwm3/default-config'
Making all in libs
make[2]: Entering directory '/home/n6tadam/projects/fvwm/fvwm3/libs'
  CC   gravity.o
  CC   BidiJoin.o
  CC   Flocale.o
  CC   PictureUtils.o
  CC   FScreen.o
  CC   Bindings.o
  CC   PictureGraphics.o
  CC   Graphics.o
  CC   FlocaleCharset.o
  CC   Parse.o
  CC   PictureImageLoader.o
  CC   Colorset.o
  CC   ColorUtils.o
PictureImageLoader.c: In function ‘PImageLoadSvg’:
PictureImageLoader.c:287:9: warning: ‘rsvg_handle_get_dimensions’ is 
deprecated: Use 'rsvg_handle_get_intrinsic_size_in_pixels' instead 
[-Wdeprecated-declarations]
  287 | Frsvg_handle_get_dimensions(rsvg, );
  | ^~~
In file included from Fsvg.h:9,
 from PictureImageLoader.c:46:
/usr/include/librsvg-2.0/librsvg/rsvg.h:727:6: note: declared here
  727 | void rsvg_handle_get_dimensions (RsvgHandle *handle, RsvgDimensionData 
*dimension_data);
  |  ^~
PictureImageLoader.c:360:9: warning: ‘rsvg_handle_render_cairo’ is deprecated: 
Use 'rsvg_handle_render_document' instead [-Wdeprecated-declarations]
  360 | Frsvg_handle_render_cairo(rsvg, cr);
  | ^
In file included from /usr/include/librsvg-2.0/librsvg/rsvg.h:1460,
 from Fsvg.h:9,
 from PictureImageLoader.c:46:
/usr/include/librsvg-2.0/librsvg/rsvg-cair

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> > A couple of patches for the parser branch:
> > 
> > 0001: Some cleanup.
> > 0003: Fix function depth handling and an uninitialised function argument.
> >   (I.e. a crash)
> 
> Thanks; applied these two.

You'll need to fix some missing #includes though, as the build's failing, but
I don't have the time to do so right now.

Kindly,
Thomas

Re: [PATCH - parser] (4) updates

[Thomas Adam]

On Fri, Nov 19, 2021 at 02:54:53AM +0100, Dominik Vogt wrote:
> A couple of patches for the parser branch:
> 
> 0001: Some cleanup.
> 0003: Fix function depth handling and an uninitialised function argument.
>   (I.e. a crash)

Thanks; applied these two.

Kindly,
Thomas

Re: [RFC] Fake a global monitor when RandR is not available.

[Thomas Adam]

On Fri, Nov 19, 2021 at 02:53:32AM +0100, Dominik Vogt wrote:
> On Fri, Nov 19, 2021 at 02:14:57AM +0100, Dominik Vogt wrote:
> > For debugging I need to run another fvwm in xnest, but that
> > doesn't support randr.
> >
> > The attached patch mocks up a global monitor to use if init fails.
> > It works at the first glance, but the patch is not very clean.
> > Please comment.
> 
> Sorry, wrong patch, this is the correct one.

I think most people have started to use Xephyr instead of Xnest, which does
support RANDR... I'd rather that than maintain a single screen.  For
reference, I did used to support that, but removed it in commit 
6e646e6201051d19dea5fa8e985fcaf884f0d94d

Kindly,
Thomas

Re: [RFC] New parser framework for testing

[Thomas Adam]

On Thu, Nov 18, 2021 at 02:19:11PM +0100, Dominik Vogt wrote:
> Most of the tests were meant to catch parsing bugs, leaks and
> crashes.  A mor organised approach in the future would be good.
> Maybe it would even be possible to generate test cases for
> commands programmatically from the BNF.

It might be -- although my faith in our accuracy of the BNF notation we came
up with isn't too strong.  Either way, I'll put something together which will
make it easy to expand.

> Sounds interesting.  While implementing new ways of selecting
> source/target (what is the difference?) it is still possible to
> keep the existing conditionals working:  If "-s ..." is present,
> use it.  Otherwise use the window that has been selected  by a
> conditional.  If that's not defined either, ask the user to select
> one.

Yes, in that order as well, I would have thought.  I'm still mulling over what
I mean by source vs target, but source refers to the window or windows which
the command needs to operate on, and target is the end result of that command.
Take the `Move` command, for instance:

Move -s  -t screen|desktop|page

But I think that's overcomplicating things.  What matters is whether the
command expects a window, or if it's a command which changes state (such as a
colorset, or a setting for something).

I think you're right though, Dominik, we need to pull this into a .md file and
start fleshing it out (similar to how we did the BNF work), if you're happy
for that?

> For multi-target conditions the syntax would work too.
> 
> Old way, loop over all windows, filter them by a resource name,
> then apply a command to them:
> 
>   All (xterm) Close
> 
> Same in new syntax (assuming "-c" marks the beginning of the
> command to execute):
> 
>   All --match-resource "xterm" -c Close

Something like that, yes.  Although I'm suggesting that filters would allow
for us doing away with commands such as: All, None, Next, Prev, as they'd
become a part of the filter.  So you might say:

Close --filter "screen:X,desk:*,class:XTerm,condition:*"

... to close all XTerm windows (condition:*), which were only on screen X,
all desks (desk:*).

Either way would work though.

> Taking it a step further filters can be applied to *any* command
> line, not just commands:
> 
>   foobarfunc --match-resource "xterm"
> 
> (Problem: How can we distinguish between general filters and the
> actual command/function arguments?)

If a command in a complex function isn't overriding the calling filter, then
use that?

> Note:  Complex functions already have a kind of filtering with the
> "I", "C", ... bits.

Yeah -- this needs more thinking.

Hmm.

Kindly,
Thomas

Re: [RFC] New parser framework for testing

[Thomas Adam]

On Thu, Nov 18, 2021 at 12:31:09AM +0100, Dominik Vogt wrote:
> I haven't found anything yet either.  Anyway, we need
> infrastructure for automated testing.  That shouldn't involve much
> more than a testing directory, a Makefile with a "test" target,
> and a couple of files that can be fed into "Read" via FvwmCommand.

We used to have something like that but it fell into bitrot and I removed it
years ago.  That being said, it's probably more valuable to have a set of
tests which capture the behaviour of the parser, than it is about checking
window positions, etc.

> Could you try to assemble a list of parsing test cases from past
> bug reports?  We don't need hundreds but a selection of relevant
> corner cases.

Sure.

> The execution context is something different.  It is basically
> meant to transport the information who or what triggered an action
> to pieces of code that need it.  For example, one might need to
> know if a window button was acticated by a mouse button press, or
> a release, from the keyboard  (from a menu entry etc.), from a
> module, and so forth.  This change was extremely successful.
> Before we had the execution context, there were loads of transient
> bugs because code had to guess how it had been called.  These
> problems are all gone now.

Indeed -- and I understood that.  My point was to try and pre-enumerate this
along with the window which is required to run the action.  That works fine
for individual commands but each item in a function could be working on a
different context entirely.  I think what I'm trying to convey here is two
different things which I shouldn't conflate.

> The biggest problem I see is that the parsed information needs to
> be passed to the commands.  I really don't want to generate C
> struct types programatically, and definitely not with odd tools
> like lex/yacc/bison.  We used them for a while, and quality of the
> generated code was somewhere below zero.

OK.

> Here's an ad-hoc list of things needed for BNF* based commands:
> (* or whatever syntax description we want to use.)
> 
>  * A precise description of the commands' syntax in BNF.
>  * A way to express alternative syntax variants.  We have several
>commands that have different modes of operation; for example
>"Move" takes certain arguments in interactive mode, some
>arguments indicate noninteractive mode, and some arguments are
>shared.

I see this as the fundamental underpinings of moving things forward.  Get this
right (or at the very least *standardised*), and everything becomes a lot
easier.

I see some of this as recognising that the commands need to have a common
syntax.  Just dreaming up something here, but take the Move command for
example:

   Move   <-- context is known or asked for, but interactive nonetheless
   Move -s fvwm.next.XTerm  <-- next XTerm in the ring (but interactive)
   Move -s fvwm.prev.XTerm -p 200p 100p <-- prev XTerm, non-interactive

(Here, -s indicates the *source* window).

Resize could also work the same with with -s

What I'm really talking myself into here is a DSL which represents the ability
to consistently apply filters to commands which operate consistently.  This
would also mean conditional commands are not a separate entity, they're just
filters operating on other commands.

Commands might collectively take '-s' to indicate a source, or '-t' to
indicate the destination.  Be it a specific geometry, pixel/percentage,
desktop, page, etc.  The syntax for these can be unified and abstracted away. 

So I think the BNF descriptions as we have them now are very useful and needed
to understand how the different commands behave now, and overlap.  But for any
future changes, we need to think differently.

I don't like the overlap we have now between commands operating as
state/settings changed, and commands which all do the same thing as one
another.  The BNF screams that to me even more than the man page does at this
point.  ;P

>  * Some way to store it in the function table (at compile time
>without making functable.h depend on all other .h files.)

Yes. 

>  * An indication in the function table whether a command uses old
>style parsing or BNF based.
>  * A way to translate the BNF to structured data, either at
>build time (a la bison) or at run time (like the X event
>unions?).

We could start adding to the function table flags to indicate deprecation,
overlaps_with, etc.  Along with parsing hints.  For example (and completely
made up):  imagine some command struct:

struct fvwm_command {
const char *cmd_name;
const char *syntax;
const char *other_cmd; <-- the alternate command to use if deprecated
int   flags; <-- deprecated
context_t *context; <-- the window to operate on, etc.
};

So here, what I'm trying to convey is capturing the state of the command we
have now, whether it's deprecated (and the command to use instead), and some
context_t which has evaluated which 

Re: [RFC] New parser framework for testing

[Thomas Adam]

On Wed, Nov 17, 2021 at 08:40:09PM +0100, Dominik Vogt wrote:
> 'k, the patched code didn't immediately crash, so here it is (two
> patches).  Please test.

I've applied those two patches on a branch called `new-parser`.

So far, I've tested this on approximately five different configuration files
and haven't noticed anything unusual or anything which breaks.  Which is a
good sign.

> The new code:
> 
>  * Rewrites functions.c to use hooks that are provided by a
>pluggable parser module (even at run time).
>  * The module that replicates the old parser behaviour is in
>cmdparser_old.[ch].
>  * The long term goal is to replace the _old parser with a new one
>that evauates the BNF definitions and does the parsing of
>function arguments before actually calling them.
>  * To allow that, a "parsing context" structure is passed to the
>CMD_... functions.  This is already implemented but not used.
>  * How the "parsing context" structure should look like is yet to
>be defined.
>  * It shoul be entirely possible to convert command functions one
>by one to the new type of parser.  So that word does not need
>to be done in a single big step.

This is sensible, and from a quick glance at what's there at the moment, it
makes sense.  I'm hoping that we can also derive the execute_context_t from
the parsed command as well, which would possibly help in unifying some of the
command syntax in the future.

I did wonder whether we might want to consider yacc/bison for the grammar of
the commands, but I've never personally been a fan of it, but it could help
wih some of the raw parsing...

> Possible pitfalls:
>  * Bad behaviour of the fvwm_debug function because of wrong
>parameters being passed.

I did a quick santity check of the ones which were pulled in from your
changes, and they look fine.  All other parser debug is going to stderr
anyway.

>  * The "repeat" command may cause crashes or leaks.

Weren't we thinking of removing the repeat command at one point?

Kindly,
Thomas

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

[Thomas Adam]

On Wed, Nov 17, 2021 at 08:18:07PM +0100, Dominik Vogt wrote:
> On Wed, Nov 17, 2021 at 04:40:55PM +0000, Thomas Adam wrote:
> > I've also added an OVERVIEW
> > section to fvwm3all.adoc explaining how the man page is split up into
> > different sections.
> 
> Shoudn't that go to fvwm3.1 as well?

I wouldn't have thought so -- in that, if you're reading fvwm3.1, you've
chosen that deliberately, or already read fvwm3all.1.  In the same way that we
wouldn't add it to fvwm3{commands,menus,styles}.1

Kindly,
Thomas

Re: parser branch

[Thomas Adam]

On Wed, Nov 17, 2021 at 01:47:05PM +, Thomas Adam wrote:
> On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> > I'd like to finish the parser work started in 2014.  Is the old
> > branch still available somewhere?
> 
> Remind me what work that was...

I remember now.  It came in two parts.  The first part, you and I worked on
documenting the commands in BNF notation (back in 2016).  That work is what
got carried across to fvwm.

Then you created some experimental code to start to clean things up.

That work was done in the mvwm repository [1], and the two branches you'll
want to look at are:

* dv/new-parser

  https://github.com/ThomasAdam/mvwm/commits/dv/new-parser

* dv/new-parser-2

  https://github.com/ThomasAdam/mvwm/commits/dv/new-parser-2

You could add mvwm as a git-remote in the fvwm3 repository and try and
cherry-pick/rebase the relevant commits.   But I suspect neither branches will
have any common ancestry with the master branch, so that might not work as
well.  But you could solve that through using grafts if you really wanted to.

I can't really remember where we got to with that work either -- I'm hoping
this trip down memory lane might jog your memory more than it has mine.  ;)

HTH,

Thomas

[1]:  https://github.com/ThomasAdam/mvwm

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

[Thomas Adam]

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.

The PR is here:  https://github.com/fvwmorg/fvwm3/pull/637

Kindly,
Thomas

Re: parser branch

[Thomas Adam]

On Wed, Nov 17, 2021 at 02:38:19PM +0100, Dominik Vogt wrote:
> I'd like to finish the parser work started in 2014.  Is the old
> branch still available somewhere?

Remind me what work that was...

Kindly,
Thomas

Re: [PATCH] (5) Man page changes

[Thomas Adam]

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.
> 
> 1, 2 and 4 are unrelated cleanups.
> 3 and 5 implement the split.
> 
> 4 conflicts with both, 3 and 5, so it can't be pulled out of the
> sequence.

I'm not able to apply these patches cleanly.  Patch 5 is failing to apply:

[~/p/f/fvwm3]{2972}[ta/manpage-sections][10bd094] % git am -3 /tmp/d/* 
Applying: Correct a sentence in the man page.
Applying: Rephrase Title style documentation.
Applying: Split main man page.
Applying: Cleanup man page.
Applying: fvwm3styles man page.
Using index info to reconstruct a base tree...
.git/rebase-apply/patch:6588: space before tab in indent.
  StaysOnTop, WindowListSkip
.git/rebase-apply/patch:6591: space before tab in indent.
  WindowListSkip
error: patch failed: doc/fvwm3_manpage_source.adoc:5186
error: doc/fvwm3_manpage_source.adoc: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0005 fvwm3styles man page.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Patches 1 - 4 before it apply just fine.

Any thoughts?

Thomas

Re: [PATCH] (2) fvwm3styles.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> Two more patches for the man page branch, this time taking care of
> the style commands.
> 
> 0001: General cleanup.
> 0002: Split of fvwm3styles.1.
> 
> Need to be applied in this order.
> 
> Please take a good look at the result of the patch stack.  I think
> this is all going in the right direction.  If you agree and see no
> problems, I'll make a fresh stack of acleaned up patches that can
> go to the master branch.

I agree -- it's looking really good.

> There are various formatting problems left, but can be fixed later.

Yes.

> --
> 
> Off-topic:  Can we remove the "globalopts" command description?

Yes.  I can see a small section that's still present.

Kindly,
Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:32:11AM +0100, Dominik Vogt wrote:
> Sorry, won't work, I've already reordered, merged and edited
> patches.  I don't want to commit a pile of junk like in CVS times.
> With Git I want much higher patch quality.  :)

I understand that -- I suppose I'm not following your development workflow.
When you're sending patches through to the list, I'm taking them as-is and
applying them on a branch from master.

For the current documentation work you're sending patches for, I'm doing the
same thing, but I presume if you're squashing or editing changes together, it
makes it harder for me to know what I'm supposed to be tracking, that's all.

Kindly,
Thomas

Re: [PATCH] (2) fvwm3styles.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:28:45AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 01:18:24AM +0100, Dominik Vogt wrote:
> > Off-topic:  Can we remove the "globalopts" command description?
> 
> And while we're at it, remove its implementation as well?
> 
> At the moment, GlobalOpts:
> 
> (1) Emits a deprecation warning ans prints the command that has to
> be used instead.
> (2) Executes that command automatically.
> 
> We could remove just (2), leaving the warning in place, or just
> eliminate the command completely.

I say remove it completely -- both its implemention and in the documentation.
I haven't seen a single config where GlobalOpts has ever been used, so I
really do think we can be quite brutal here.

It's about time.

Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Tue, Nov 16, 2021 at 01:13:24AM +0100, Dominik Vogt wrote:
> On Tue, Nov 16, 2021 at 12:09:41AM +0000, Thomas Adam wrote:
> > On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> > > On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > > > 0001: Some man page cleanup.
> > > > 0002: New man page fvwm3menus.1
> > >
> > > 0003: Fix list formatting (attached).
> >
> > I've applied these three patches now, thanks.
> >
> > They still did not apply cleanly on top of ta/dv-manpage-sections, so I had 
> > to
> > manually modify a few sections with the .rej file.
> >
> > Can you check I've not mangled anything?  I do note some formatting
> > inconsistencies when viewing fvwm3menus.1 but I don't think that's related 
> > to
> > any changes made so far.
> 
> Just ignore it, I'll make a cleaned up series later, so we can
> dump the branch.

That's fine.  I'm using that branch to collect all the documentation changes
you're sending through as it's easier to manage -- so if those patches could
be based from that branch, it would certainly help.  :)

Kindly,
Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Mon, Nov 15, 2021 at 11:57:54PM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> > 0001: Some man page cleanup.
> > 0002: New man page fvwm3menus.1
> 
> 0003: Fix list formatting (attached).

I've applied these three patches now, thanks.

They still did not apply cleanly on top of ta/dv-manpage-sections, so I had to
manually modify a few sections with the .rej file.

Can you check I've not mangled anything?  I do note some formatting
inconsistencies when viewing fvwm3menus.1 but I don't think that's related to
any changes made so far.

Kindly,
Thomas

Re: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

[Thomas Adam]

On Mon, Nov 15, 2021 at 11:38:36PM +0100, Dominik Vogt wrote:
> 0001: Some man page cleanup.
> 0002: New man page fvwm3menus.1

Are these patches based off the ta/dv-manpage-sections branch?  They don't
apply cleanly via 'git am'.

> The ending text goes back to the indentation of the section
> heading, or ig "+" is used it's indented like the list text.
> 
> The workaround is to start a new list with smaller indentation with
> 
> --snip--
> .::
> --snip--
> 
> But that creates an additional "." heading.  See line 2904.

Yes.  I've not found a good solution to this.   I suppose I could ask the
asciidoctor maintainers...

Kindly,
Thomas

Re: [PATCH] Fix resize calculations.

[Thomas Adam]

On Mon, Nov 15, 2021 at 09:37:48PM +0100, Dominik Vogt wrote:
> The earlier patch broke resize calculations by making windows too
> big.  This patch fixes this.

Makes sense.  I'm surprised I've not noticed that during the working day.

Applied now, thanks.

-- Thomas

Re: [RFC] Splitting the man page

[Thomas Adam]

On Mon, Nov 15, 2021 at 09:00:43PM +0100, Dominik Vogt wrote:
> Now, about the contents of the new man pages:  Splitting has not
> bought us that much yet.  75% of the contents are now in the
> commands man page.  It's difficult to remove more things from that
> because the command list also contains general topics like menus,
> session management and coloursets.  Moving these parts to
> different pages would also remove them from the command list.  The
> original man page just has a bad structure.

I suppose another way of looking at it might be to trying to convey things in
terms of functional areas, almost looking at things that a user might want as
they're configuring fvwm.   Right now, we're trying to lump together a lot of
similar things.  We could go further and have something like:

* An overview section explaining the anatomy/role of the window manager,
  explaining things such as:

  - Windows (decorations, anatomy, etc.)
  - Menus
  - Core functionality
  - Extending functionality (modules)

For explaining windows, we could enumerate the styles which are specific to
manipulating windows.  Grouping them by EWMH, window movement, etc.  Then we
would need an "fvwmallstyles" man page which aggregates these together.

> It's not obvious how to move the Style command (a subsection of
> the commands page) to a different file without cluttering the
> source with ifdefs.

That's a small price to pay for trying to increase readability, IMO.

Kindly,
Thomas

Re: [RFC] Splitting the man page

[Thomas Adam]

On Mon, Nov 15, 2021 at 05:13:47PM +0100, Dominik Vogt wrote:
> 2) The Makefile.am now uses the standard "man1_MANS" file type to
> describe the generated files.  That should make local installation
> rules unnecessary.  Not sure whether it also handles the
> "transform" stuff or not.  For now I've removed it.

We'll need to support the transform stuff, as I know some packagers use it.

> 3) There's a new, experimental page "fvwm3commands.adoc" which
> has a header and then just includes the file
> fvwm3_commands.section.  This file is generated from fvwm3.adoc by
> extracting all text between the two comments
> 
>   // BEGIN 'commands'
>   ...
>   // END 'commands'

I think this is a good approach.  Something in the back of mind tells me this
is something which asciidoc(tor) supports, although it's a moot point as this
is lightweight enough that it's not going to introduce any overhead.

> Sections to extract are listed in the variable "EXTRACT_SECIONS".
> For now, all man pages simply depend on all section files.  To
> build real dependencies we'd have to extract the include
> directives from the .adoc files, but this seems to be overkill.

git.git do something like this for their built documentation (also written in
asciidoc).  But I suspect we won't need this -- it's probably going to be more
relevant if we ever do something about the *content* -- which is a different
issue entirely to just sorting out the structure.

> 4) Also removed the "QUIET_ASCIIDOC" thing because it seems to be
> pointless to suppress single-line rules in the output.  (Don't
> care much about it, though.)

Hmm.  I'm sure I added that because of some weird CI/CD interactions I was
seeing with Github Actions, but I think that's now solved.

> 5) fvwm3.1 still contains everything.  I'd like to rename that to
>fvwm3all.1 and then find a way to create fvwm3.1 without the
>sections that have their own page, containing placeholders that
>point to the other pages.

Agreed.  I'm sure there's an asciidoc(tor)-specific way of being able to do
this.

> Seems to do what is intended; "make install" and "make uninstall"
> work fine, but I haven't tried to build and test a distro from
> that.

Worked well for me.

This work is now being tracked here:

https://github.com/fvwmorg/fvwm3/pull/637

Via the `ta/dv-manpage-sections` branch.

Kindly,
Thomas

Re: [PATCH] (7) Miscellaneous cleanup

[Thomas Adam]

On Mon, Nov 15, 2021 at 12:11:51PM +0100, Dominik Vogt wrote:

Thanks.  Will apply.  With respect this this patch:

> 0007: Remove the "MWM COMPATIBILITY" section.  Nobody cares anymore.

Presumably the "OPEN LOOK AND XVIEW COMPATIBILITY" section can go as well?

Kindly,
Thomas

Re: [PATCH] (2) Remove Dmalloc and Efence support.

[Thomas Adam]

On Mon, Nov 15, 2021 at 02:07:58AM +0100, Dominik Vogt wrote:
> 0001: Remove Efence and Dmalloc support.
> 0002: Remove trailing whitespace.

Applied.  Thanks!

Kindly,
Thomas

Re: Removind dmalloc and efence support?

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:42:33AM +0100, Dominik Vogt wrote:
> Has anybody really used them in the last fifteen years?  Since
> valgrind has become pretty stable and good I never saw a need for
> dmalloc or efence any more.

I agree.  It can go.  There's a chance some distros ship efence (and possibly
the BSDs), but it all pales in light of Valgrind.

I know Dan used to use one of the proprietary IBM profilers on fvwm's code
base from time-to-time as well, but I don't recall what that was called.

Kindly,
Thomas

Re: Plans for the NEWS file?

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:40:40AM +0100, Dominik Vogt wrote:
> There probably needs to be some time when we annouce that we're
> done removing stuff so that people know that future changes will
> no longer break their configs.  I'd say the feature set is
> unstable at the moment, not the code quality.

Right, I understand.  Yeah, that's fair.  I think the majority of the bigger
breaking changes have largely happened (such as deprecating certain modules),
but you're right -- we should take stoke of that, and what's left and make
that a focus of the release schedule(s).

Kindly,
Thomas

Re: Paging issue

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:36:15AM +0100, Dominik Vogt wrote:
> While we're at it, much of the markup could be removed.  The
> manpage is partially unreadable because too many words have markup
> (especially for the style command).

Yeah.  I suspect this is a holdover from when the original man page was in raw
Groff format, where such markup was quite common, and that's carried over from
Dockbook -> Asciidoc.

> (Also, the Style docuementation should possibly be put in a
> separate manpage.  The monolithic manpage is intimidatingly large.
> Even I am reluctant to use it.  Maybe like the zsh manpages: One
> manpage per larger topic, and if you really insist on an ugly big
> one, there's also "man fvwmall".  Should be generated from a
> single source though.)

That's now significantly easier thanks to Asciidoc being in use, I agree --
and it's a subject which has come up over the years.  I like the idea -- and
we can definitely start with styles.  As you say, that's the bigger area of
documentation.  I've also never been a fan of styles being documented like this:

Foo / Bar / Baz

Where the last one in the group (Bqz, in this case) is meant to be the
default.  I suspect that convention hasn't been honoured properly for years,
and we can certainly regroup these things to make it mor readable.

> > I think it's best to try and keep line length to <=80 characters
> 
> Sounds good.  If we could add the emacs config for that at the
> start of the file that would help.  (Just press alt-q to reformat
> a block.)

I've been trying to move away from that convention in favour of using
editorconfig:

https://editorconfig.org/

There's already a .editorconfig file in the top-level git repo.  We could add
the relevant section for .adoc files and then that would also apply to Vim as
well (which is what I use).

Kindly,
Thomas

Re: [PATCH] (3) Miscellaneous updates

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:26:31AM +0100, Dominik Vogt wrote:
> 0001: Improve Snap... docuemntation.
> 0002: Improve EdgeMoveDelay documentation.
> 0003: Remove superfluous "#if 1".

Applied, thanks!

Kindly,
Thomas

Re: Plans for the NEWS file?

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:18:49AM +0100, Dominik Vogt wrote:
> Is the NEWS file going to be used for 3.x releases too?  I always
> found it easier to add new entries when patches are written
> instead of reading the whole changelog when making a release.

I now autogenerate this at release time via Github Actions, where the
relevant bugs/pull-requests, etc., are pulled from Github and formatted
accordingly in CHANGELOG.md

> Can you give me an update on the intended release scheme?  Fvwm is
> probably in an "unstable" phase at the moment?

Right now, I've pre-scoped bugs/PRs/etc., which I feel should be in the 1.0.5
release here:

https://github.com/fvwmorg/fvwm3/projects/1?card_filter_query=milestone%3A1.0.5

This is somewhat arbitrary on my part in that there's no real end-goal for a
given release, other than what I think should be in it -- and typically what
I've been doing is amassing changes and releasing when it feels right, even if
items against that milestone might not yet have been finished.  In such cases,
those items are moved forward to the next release.

I don't think fvwm is in an "unstable" phase.  It seems to be "OK", although
there's many rough edges still left to tidy up -- not helped by my own
butchery of fvwm over the past year...

HTH,
Thomas

Re: Paging issue

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:16:06AM +0100, Dominik Vogt wrote:
> Of course.  What is the maximum line length that was used to
> format the .adoc files?  (Can we re-add some formatting
> instructions in comments at the start of the main manpage source
> as we had in the groff sources?  I've noticed that style names are
> sometimes underlined and sometimes in italics.)

There's some clean up that still needs doing, due to the conversion script I
wrote (albeit badly) to convert from XML -> Asciidoc, so I am not surprise if
you find any glitches.  I suspect there's quite a few of them!

I think it's best to try and keep line length to <=80 characters, although
there's probably going to be times where that's not possible if the formatting
rules require lines to exceed that.

Kindly,
Thomas

Re: [PATCH] Reject out of range windows for Move and Resize commands.

[Thomas Adam]

On Mon, Nov 15, 2021 at 01:11:34AM +0100, Dominik Vogt wrote:
> Fixes programs going crazy when you accidentally say something like
> 
>   all (mplayer) resize 1920 1200
> 
> instead of
> 
>   all (mplayer) resize 1920p 1200p
> 
> (Generates an error message without doing anything else.)

Makes sense, Dominik.  Will apply.

Thanks!

Thomas

Re: Paging issue

[Thomas Adam]

On Mon, Nov 15, 2021 at 12:31:28AM +0100, Dominik Vogt wrote:
> On Mon, Nov 15, 2021 at 12:19:59AM +0100, Dominik Vogt wrote:
> > What do you think about the attached patch?  Pressing "Alt" during
> > an interactive move already disables snapping.  It's easy to make
> > it enable paging without any delay too.  I like it.
> >
> > You can say
> >
> >   style * edgemovedelay
> >
> > (to disable paging during normal moves), then press Alt for a
> > second to switch pages, then release Alt to go back to normal
> > mode.
> 
> P.S.:  Does not work with "Resize" yet.

Noted.  I like this, and I think it will also work well for Resize.  Also
needs a quick manpage update.

Kindly,
Thomas

Re: Paging issue

[Thomas Adam]

On Sun, Nov 14, 2021 at 04:50:23PM +0100, Dominik Vogt wrote:
> Current situation for me:  At least 90% of all paging situations
> are accidents.

Yeah, and it gets even worse if you happen to use paging with
'DesktopConfiguration per-monitor' as well.

> Maybe that feature ist just crap and we need a different mechanism
> to trigger paging.  Like holding down Shift while moving etc.

I'd like to see this.   I know it's a departure from how we've always handled
paging, but I find myself doing things like:

EdgeScroll 0 0

For all the reasons you've previously mentioned, Dominik, I like to be able to
sometimes flip pages using panframes but find it so utterly annoying I turn
that off, and then end up not using pages, but rather desks -- hence it's
equivalent to just me using a 'DesktopSize 1x1'.

I say we should implement this change and see how it works in practise.  If
enough people don't like it, I'm sure they'll let us know.  :)

Kindly,
Thomas

Re: Paging issue

[Thomas Adam]

On Sun, Nov 14, 2021 at 01:55:32PM +0100, Dominik Vogt wrote:
> 1) Because the pointer is at the top of the screen, it's
> immediately in the one pixel high panning window, so fvwm waits
> the configured 500 ms and then switches pages to 0 0 although
> neither the window nor the pointer have ever moved.
> 
> 2) Even worse, _because_ nothing has moved, the window ist still
> completely on page 0 1.  Not a single pixel is visible.
> 
> Overall, the implementation of paging is annoying, and Ive no idea
> how to fix it.

Presumably, the point here is to not do anything until the pointer has
moved, even if it is already in the panframe window?

Kindly,
Thomas

Re: [PATCH] 1/3 Fix and document "bugopts debugrandr".

[Thomas Adam]

On Sun, Nov 14, 2021 at 10:58:19AM +0100, Dominik Vogt wrote:
> The patch makes the bogus "bugopts debugrandr" option actually do
> something.

Hi Dominik,

Thank you.  All four patches have now been merged!

Thanks,
Thomas

[fvwmorg/fvwm] 6e4fb0: README: correct markdown syntax

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6e4fb093541f263b4bca0231767cc4cd41850a20
  
https://github.com/fvwmorg/fvwm/commit/6e4fb093541f263b4bca0231767cc4cd41850a20
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: correct markdown syntax

[fvwmorg/fvwm] 6e4fb0: README: correct markdown syntax

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 6e4fb093541f263b4bca0231767cc4cd41850a20
  
https://github.com/fvwmorg/fvwm/commit/6e4fb093541f263b4bca0231767cc4cd41850a20
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: correct markdown syntax

[fvwmorg/fvwm] 4df413: README: clarifications and typo fixes

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: 4df413509888555d063a7cb12c9f899e8712acd3
  
https://github.com/fvwmorg/fvwm/commit/4df413509888555d063a7cb12c9f899e8712acd3
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarifications and typo fixes

[fvwmorg/fvwm] ea7ed8: Update README.md

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: ea7ed81c7654bddf7dd57df23be2538038225ffa
  
https://github.com/fvwmorg/fvwm/commit/ea7ed81c7654bddf7dd57df23be2538038225ffa
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.


  Commit: 4df413509888555d063a7cb12c9f899e8712acd3
  
https://github.com/fvwmorg/fvwm/commit/4df413509888555d063a7cb12c9f899e8712acd3
  Author: Thomas Adam 
  Date:   2019-08-25 (Sun, 25 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarifications and typo fixes


Compare: https://github.com/fvwmorg/fvwm/compare/a61c970b8632...4df413509888

[fvwmorg/fvwm]

[Thomas Adam]

  Branch: refs/heads/ThomasAdam-patch-1
  Home:   https://github.com/fvwmorg/fvwm

[fvwmorg/fvwm] ea7ed8: Update README.md

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: ea7ed81c7654bddf7dd57df23be2538038225ffa
  
https://github.com/fvwmorg/fvwm/commit/ea7ed81c7654bddf7dd57df23be2538038225ffa
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.

[fvwmorg/fvwm] f4a498: Update README.md

[Thomas Adam]

  Branch: refs/heads/ThomasAdam-patch-1
  Home:   https://github.com/fvwmorg/fvwm
  Commit: f4a498d442bf6a6bafc314889b5e7c3b2ec3311f
  
https://github.com/fvwmorg/fvwm/commit/f4a498d442bf6a6bafc314889b5e7c3b2ec3311f
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  Update README.md

Fix formatting.

[fvwmorg/fvwm] a61c97: README: clarify development situation

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm
  Commit: a61c970b863267301a92722fcd0d7e6f8968aae9
  
https://github.com/fvwmorg/fvwm/commit/a61c970b863267301a92722fcd0d7e6f8968aae9
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarify development situation

[fvwmorg/fvwm] a61c97: README: clarify development situation

[Thomas Adam]

  Branch: refs/heads/ta/update-readme
  Home:   https://github.com/fvwmorg/fvwm
  Commit: a61c970b863267301a92722fcd0d7e6f8968aae9
  
https://github.com/fvwmorg/fvwm/commit/a61c970b863267301a92722fcd0d7e6f8968aae9
  Author: Thomas Adam 
  Date:   2019-08-24 (Sat, 24 Aug 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README: clarify development situation

Re: [PATCH] Fix FvwmMakeMissingDesktopMenu

[Thomas Adam]

On Wed, Aug 21, 2019 at 01:12:47PM +, Luke Lau wrote:
> From: Luke Lau 
> 
> This drops the obsolete --fvwm-icons flag and specifies to add it into
> the "Desktop Programs" menu

Thanks.  Looks fine to me.  Will apply this over the weekend.  If you don't
see this land in fvwm2 early next week, please do chase me.

Kindly,
Thomas

[fvwmorg/fvwm3] bdeed0: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: bdeed0543087b69f7b9c672dd061fdb3801faebe
  
https://github.com/fvwmorg/fvwm3/commit/bdeed0543087b69f7b9c672dd061fdb3801faebe
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] d8634f: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: d8634f25a205fae1a500eeba601be7f4e8998401
  
https://github.com/fvwmorg/fvwm3/commit/d8634f25a205fae1a500eeba601be7f4e8998401
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] f51066: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: f51066189b9745cc80caa16108e5ae33a418dd61
  
https://github.com/fvwmorg/fvwm3/commit/f51066189b9745cc80caa16108e5ae33a418dd61
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 09226a: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 09226a68ed130ea1fd07f8dd8f77513989e91702
  
https://github.com/fvwmorg/fvwm3/commit/09226a68ed130ea1fd07f8dd8f77513989e91702
  Author: Thomas Adam 
  Date:   2019-05-16 (Thu, 16 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] e423e7: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: e423e76e786ef937bb33cd8ae96bb5da3b19be69
  
https://github.com/fvwmorg/fvwm3/commit/e423e76e786ef937bb33cd8ae96bb5da3b19be69
  Author: Thomas Adam 
  Date:   2019-05-15 (Wed, 15 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 57819c: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 57819ccf5f760f4cebf7f73fdc37555c2b2fab28
  
https://github.com/fvwmorg/fvwm3/commit/57819ccf5f760f4cebf7f73fdc37555c2b2fab28
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 8024f6: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 8024f6d66bb1452b711a70c221e643b7bfcb7d74
  
https://github.com/fvwmorg/fvwm3/commit/8024f6d66bb1452b711a70c221e643b7bfcb7d74
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] 885e5a: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: 885e5a70eefe0235bca9cdfd4a5b7d2a48e9d470
  
https://github.com/fvwmorg/fvwm3/commit/885e5a70eefe0235bca9cdfd4a5b7d2a48e9d470
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M .travis.yml
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] b3eb85: read: remove custom fgets logic and use fparseln()

[Thomas Adam]

  Branch: refs/heads/ta/fparseln
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: b3eb85fe9a6f930e21a4018720f6157fbd0bdea5
  
https://github.com/fvwmorg/fvwm3/commit/b3eb85fe9a6f930e21a4018720f6157fbd0bdea5
  Author: Thomas Adam 
  Date:   2019-05-14 (Tue, 14 May 2019)

  Changed paths:
M configure.ac
M fvwm/Makefile.am
M fvwm/read.c

  Log Message:
  ---
  read: remove custom fgets logic and use fparseln()

When reading in a configuration file (or anything which uses the
Read/PipeRead command), there's always been a hard-limit of a
configuration line being no more than 1024 bytes.  This was fine
historically, but this restriction is now rather limiting.

This change solves that by using fparseln() from libbsd.  This also has
the added advantage that it can handle line continuations, which was
also part of the hand-rolled logic mentioned above.

Because of this change, there's now a hard dependency on libbsd for
non-BSD systems.

[fvwmorg/fvwm3] d036d0: WIP: NEW-COMMANDS.md

[Thomas Adam]

  Branch: refs/heads/master
  Home:   https://github.com/fvwmorg/fvwm3
  Commit: d036d0eca0a3825f92d6bd6d3df9b6006ec34178
  
https://github.com/fvwmorg/fvwm3/commit/d036d0eca0a3825f92d6bd6d3df9b6006ec34178
  Author: Thomas Adam 
  Date:   2019-05-06 (Mon, 06 May 2019)

  Changed paths:
A dev-docs/NEW-COMMANDS.md

  Log Message:
  ---
  WIP:  NEW-COMMANDS.md


  Commit: 8dd75710299197a2beaa5bebe27b6b680641ea0d
  
https://github.com/fvwmorg/fvwm3/commit/8dd75710299197a2beaa5bebe27b6b680641ea0d
  Author: Thomas Adam 
  Date:   2019-05-13 (Mon, 13 May 2019)

  Changed paths:
M README.md

  Log Message:
  ---
  README.md: update with link to NEW-COMMANDS.md


Compare: https://github.com/fvwmorg/fvwm3/compare/0efbd1b0366a...8dd757102991

Re: Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

On 7 May 2016 14:46, "Thomas Funk" <t.f...@web.de> wrote:
>
> On 05/07/2016 12:40 PM, Thomas Adam wrote:
>>
>> Hi all,
>>
>> Just looking through a few things, and I thought I'd ask whether fvwm
needs to
>> stlil support color limiting, and color depths for XServers with less
than
>> TrueColor?
>>
>> These days, 24-bit seems to be the standard, and indeed, I've never yet
come
>> across a server still using only 256 colours.  Whilst I appreciate you
can
>> still go and find such things, do we actually need fvwm to supprort it?
>
>
> I would suggest to swap out the functionality into a module like bidi but
> don't know how hard it is to do that ...

That's not the point, and wouldn't help here. Shuffling code around like
this isn't an option and wouldn't achieve anything. Furthermore, there's no
need to libify depth/colour limiting, such a thing doesn't make sense. It's
a capability, not something to be used directly.

> Does removing color limiting affecting things like remote connections?

No, it wouldn't.

-- Thomas Adam

Do we still need color-limit/visual options in fvwm?

[Thomas Adam]

Hi all,

Just looking through a few things, and I thought I'd ask whether fvwm needs to
stlil support color limiting, and color depths for XServers with less than
TrueColor?

These days, 24-bit seems to be the standard, and indeed, I've never yet come
across a server still using only 256 colours.  Whilst I appreciate you can
still go and find such things, do we actually need fvwm to supprort it?

Kindly,
Thomas

Man page now in rst format (WAS: Re: RFH: manpages in markdown)

[Thomas Adam]

On Mon, Apr 04, 2016 at 11:14:59PM +0100, Thomas Adam wrote:
> Hi all,
> 
> I've started to look at moving away from using docbook for man page
> generation, and instead using markdown as the base format which can then be
> converted to nroff and HTML, etc.

So I've looked again.  markdown is an OK format for this, but the generation
of markdown -> nroff is far from perfect.

Thankfully, there's RST (http://docutils.sourceforge.net/rst.html) which can
be used instead; similar to Markdown if nothing else.  On most systems,
there's rst* programs from the 'python-docutils' package which we can use to
provide the conversion.

To that end, I've removed everything in doc/* and instead, added a 'manpages'
directory with a single file in there which is the basis file for the fvwm man
page.

The conversion was automatic from HTML.  It will need a few tweaks, but
running:

rst2html manpages/fvwm.rst > manpages/fvwm.1

and then viewing the man page:

mandoc ./manpages/fvwm.1 | less

is a good start.

Anyone who wants to pick this up, do please let me know.  I'll also add this
into the the build at some point, assuming people are happy with this as a way
forward.

Historically, writing the documentation has been a reason for turning
developers away.  I hope using RST simplifies that.

-- Thomas Adam

Re: Some advices about the new static website

[Thomas Adam]

On 19 April 2016 at 14:57, Thomas Funk <t.f...@web.de> wrote:
> One idea came to my mind after clicking Support->FVWM Forums ...
> Is it possible to show the forums inside the window? ^^

No, thanks.  You'd have to use some sort of iframe to do that.  I
think what would be easier is to make the menu link a redirect to
fvwmforums.org, and remove the contents from the support page on
fvwm.org, since going to the forums speaks for itself.

-- Thomas Adam

Re: Release versioning and tagging

[Thomas Adam]

On Fri, Apr 15, 2016 at 03:14:01PM +0100, Thomas Adam wrote:
> I'll let this sit around for a bit.  If no one has any comments/objections,
> I'll merge it soon enough.

Merged.

-- Thomas Adam

Release versioning and tagging

[Thomas Adam]

Hi all,

I've done some work to try and improve how releases of FVWM happen.  Now that
we're using git, it makes sense to me that building FVWM should use the
information stored in git to detect the release information.

This also has the benfit that we can also see where in git versions of FVWM
might have come from (when talking about debug builds, etc.)

So from now on the release versions are taken from the tagged status of git.
Tag names will be in the form 'x.y.z' so that will be '2.6.7' from the next
point on.   The older naming of 'version_x_y_z' is completely deprecated.

The one potential downside to this is that non-released versions will struggle
with the internal version check, that is:

Test (Version >= 2.6.5) Echo foo

Since the version will not be in that form (deliberately).  I consider this a
feature and this won't be something I'm going to worry about, since such
builds from git in this way are in-development anyway.

You can view the work I've done here:

https://github.com/fvwmorg/fvwm/pull/4

I'll let this sit around for a bit.  If no one has any comments/objections,
I'll merge it soon enough.

Kindly,
Thomas Adam

Re: Some advices about the new static website

[Thomas Adam]

On Sat, Apr 09, 2016 at 12:40:54AM +0200, Thomas Funk wrote:
> 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.

Yes, since I disabled snapshot builds ages ago.

Again, there'll only ever be one set of man pages.

-- Thomas Adam

Re: Some advices about the new static website

[Thomas Adam]

On Fri, Apr 08, 2016 at 11:33:05PM +0200, Thomas Funk wrote:
> I could help you if you like as I did much inside Fvwm-Nightshade with
> perllib.

I'll let you know when I've put this together.

> > As for unstable man pages, no.  There's no such thing any more, and
> >hasn't been for a long time now.
> 
> 'unstable' was only used as example. As I remember the same pages exists
> on 'stable', too. But it would be a shame to lost those pages. Also Dan
> did much work on the linking on the FVWM page.

Maybe, but again, there'll only ever be one set of man pages to reflect when
releases happen.  Since I've put in place a means of generating them from
markdown (and have yet to receive offers on help with that), I'll see what
happens when I have time to look at this.

I'm not clear what you're referring to with "linking" either. But no
information has been lost that's important.

-- Thomas Adam

Re: Some advices about the new static website

[Thomas Adam]

On Fri, Apr 08, 2016 at 09:44:48PM +0200, Thomas Funk wrote:
> What about the perlib pages and the ... uhm ... 'unstable' documentation
> pages (http://fvwm.org/doc/unstable/index.html)? Will they appear again
> in the future?

perllib maybe (althought woefully out of date, and it's on my TODO list to
look at).  As for unstable man pages, no.  There's no such thing any more, and
hasn't been for a long time now.

> Btw I have some website links for our 'Links' page:
> 
> History
> ---
> In the beginning was ...
> http://edulinux.homeunix.org/fvwm/user_enumerate.html

Really?  That shouldn't resolve at all.  You mean:

http://www.xteddy.org/fvwm/user_enumerate.html

> Other FVWM-related sites
> 
> How Styles are Applied
> http://linuxgazette.net/127/adam.html
> 
> Fvwm and Session Management
> http://linuxgazette.net/100/adam.html
> (perhaps a little bit outdated but anyway interesting)

It'll still work with xsm(1).

-- Thomas Adam

RFH: manpages in markdown

[Thomas Adam]

Hi all,

I've started to look at moving away from using docbook for man page
generation, and instead using markdown as the base format which can then be
converted to nroff and HTML, etc.

Using markdown for this seems sensible---using just nroff (or my preference,
mdoc) is one solution, but not as accessible to everyone, and since we've a
*lot* of options in FVWM, the documentation needs to be easier to manipulate
and have others contribute to, hence why I'm keen to go with plain text in
this regard.

So far, I've got something lashed together, but it is just mechanical
conversions at the moment.  There's a lot more that needs to happen which I'll
outline below.  However, I'm hoping I'm not the person to do this, although
I'll happily help/mentor anyone who wishes to pick up from where I've started.

What I've done so far is used pandoc to convert the existing Docbook files
(XML) to Markdown.  I've not checked extensively whether this was successful,
but by-and-large it seems to have been.

Then, I moved all the generated files to a new top-level directory, "manpages"
and added a file in there called ORDER which details how the Markdown files
should be catted together to form one huge markdown file which will be the
fvwm man page.

There's a script called 'generate_manpages.sh' which does all of this
mechanically.   Run it from within the manpages directory.

The conversion of markdown -> nroff is done using a program called 'ronn',
found here:

https://github.com/rtomayko/ronn

But all is not perfect.   Install 'ronn' and see for yourself what it spits
out.

Anyone who's interested in this needs to:

* Audit the markdown files to ensure the conversion is complete;
* Think whether we need all of the individual .md files or whether we can
  amalgamate.  I suspect we can quite a bit.  I'm keen not to see one huge
  file again.
* Fix up a lot of warnings from the markdown files converting to nroff;
* Hook these things into the buildsystem, removing the Docbook files.

Any questions, do please ask.  Any offers of help, *definitely* let me know.
You can find my efforts here:

https://github.com/fvwmorg/fvwm/tree/ta/docs-to-md

Specifically, the 'ta/docs-to-md' branch.

Kindly,
Thomas Adam

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

[Thomas Adam]

On Mon, Apr 04, 2016 at 11:56:47AM -0600, Jaimos Skriletz wrote:
> https://help.github.com/articles/using-a-custom-domain-with-github-pages/
> https://help.github.com/articles/setting-up-your-pages-site-repository/

I say we trial this, as it's the simplest change, without additional overhead,
and we are then directly able to tweak things as we see fit.

Jason, are you OK with this?

Kindly,
Thomas Ada

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

[Thomas Adam]

On Sat, Apr 02, 2016 at 02:45:22PM -0400, Dan Espen wrote:
> Jaimos Skriletz  writes:
> 
> > 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.
> 
> If I recall  correctly, we created Changelog, and AUTHORS  in the source
> tree because its a recommended part of a GNU source tree.
> (Similar to INSTALL, README, NEWS.)

Yes, but not required, thankfully.

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

[Thomas Adam]

On Sat, Apr 02, 2016 at 11:58:41AM -0600, Jaimos Skriletz wrote:
> 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.
> ​

It can be removed.

> > 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.

The point here is to put the files which relate to the website into the
repository which handles the web site, and for other files to remain outside of
it.  For the website, this includes:  authors, faq.  Developing happens in
FVWM and although you could link to that file in the FVWM.git repo, I wouldn't
bother.

>- A simple/minimal "default" config.

This has to then be maintained by us.  Maybe, but no thanks.  We've done this
in the past, and no one has maintained it.  There's such a plethora out there
on the Internet, just link to those.

>- 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).


This can move to the wiki.

> 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).

Redirect to other sites for that sort of thing.  As for moving the wiki to
somthing on GH, sure.  But that's a different conversation and has no bearing
on the transition of the web site.

-- Thomas Adam

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

[Thomas Adam]

On Fri, Apr 01, 2016 at 02:47:24PM -0600, Jaimos Skriletz wrote:
> ​​
> 
> 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).

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.

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.

> 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.
 
> 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?

You've got a whole bunch of files that shouldn't be committed; will discuss
this with you on IRC if you like, and we've a little bit of work to do with
tidying up, but from what I can tell, this looks more-or-less complete.

Good job!

Thomas Adam

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

[Thomas Adam]

On 26 March 2016 at 01:11, Dan Espen <des...@verizon.net> wrote:
> My account is named "danespen".

I've added you, along with Jaimos as well.  My last official act
before I move onto a few more important things for a bit.

>> Note that I'm getting married this weekend and will then be away on
>> honey moon for two weeks.
>
> Enjoy and don't even think about Fvwm.

What's Fvwm?  ;)

> I've no specific plans for retirement.
> I'm on my own and starting over.

I wish you all the best, Dan.

-- Thomas Adam

Re: [fvwmorg/fvwm] c6de88: distcheck2: remove bzip2 archive generation

[Thomas Adam]

Hi,

On 25 March 2016 at 22:57, GitHub <nore...@github.com> wrote:
>   Branch: refs/heads/ta/makedist-no-bzip2
>   Home:   https://github.com/fvwmorg/fvwm
>   Commit: c6de883d85466cdc4c3ee4fc6b8ee3f5c87b8af0
>   
> https://github.com/fvwmorg/fvwm/commit/c6de883d85466cdc4c3ee4fc6b8ee3f5c87b8af0
>   Author: Thomas Adam <tho...@fvwm.org>
>   Date:   2016-03-25 (Fri, 25 Mar 2016)
>
>   Changed paths:
> M Makefile.am
>
>   Log Message:
>   ---
>   distcheck2: remove bzip2 archive generation
>
> Having two sets of generated archives was always wasteful, and the release
> mechanism on Github only allows for zip or tar.gz to be uploaded, making the
> bzip2 archive redundant.

To that end---and to illustrate---I've opened up a PR (pull-request)
for this here:

https://github.com/fvwmorg/fvwm/pull/1

You'll note that I cannot merge this to master, even though I have the
rights, until the build has passed.

As and when people here gain commit-bit rights on the repository,
"Watching" the repository will send out emails to you whenever issues
and/or pull-requests are made.

-- Thomas Adam

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

[Thomas Adam]

On Fri, Mar 25, 2016 at 05:37:50PM -0500, Jason L Tibbitts III wrote:
> >>>>> "TA" == Thomas Adam <tho...@fvwm.org> writes:
> 
> TA> I note that it's possible to set up webhooks on repositories on
> TA> Github.  We could use that mechanism to notify you of changes which
> TA> need pulling (and hence, enact some script to do a git-pull), rather
> TA> than polling for them.
> 
> It's probably not worth the effort compared to running a cron job every
> few minutes, but if it's easy then I'll at least try.

I think it's worth exploring, and I've done it before for other notification
things.

> I'm OK with continuing to maintain the site this way, but I'm not going
> to complain if you want to move it all to github.  What I really want to
> do is get away from having to keep the CVS server running.

Of course, I'm surprised you hadn't burned it already.  :)

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

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

[Thomas Adam]

On Fri, Mar 25, 2016 at 04:43:53PM -0500, Jason L Tibbitts III wrote:
> OK, a manual pull worked.  Turns out that the update script is in my
> home directory, which isn't accessible without a kerberos ticket.
> That's fixed up.

TGTs.  Nice!

> It's a trivial matter to have this do a git pull instead, so if the
> fvwm-web repository on github is up to date, then just let me know and
> I'll switch over.

I keep thinking about that; it's certainly an option.  Perhaps we can trial
this to see how it goes.  I note that it's possible to set up webhooks on
repositories on Github.  We could use that mechanism to notify you of changes
which need pulling (and hence, enact some script to do a git-pull), rather
than polling for them.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

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

[Thomas Adam]

On Fri, Mar 25, 2016 at 04:00:19PM -0600, Jaimos Skriletz wrote:
> 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.

Hi Jaimos,

> 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.

So the domain is controlled by "us", but in reality, it's Jason who's
responsible for that.

The fvwm-web documentation (if you can call it that) is found here:

http://fvwm.org/documentation/dev_cvs.php#fvwm-web

Note the scripts (I've mentioned them in other threads here) which link
through to the fvwm repo.  That's an aspect we have to change---what's needed
on the website stays in the website, so if we have to move files into that,
sobeit.

Other than that, everything is in PHP.  When the website is updated (currently
with 'cvs update') then that's polled sometime later via a cronscript which
makes the content live on fvwm.org

> 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.

Thanks!

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

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

[Thomas Adam]

On Fri, Mar 25, 2016 at 05:21:27PM -0400, Dan Espen wrote:

Hi Dan,

> My first impression, it's Github only.

No, not at all.  It's a way of generating HTML from static templates, which
can be augmented with CSS and extra HTML where necessary.  It just so happens
that what Github hosting offers, is Jekyll support out-of-the-box.

> I lean toward writing plain HTML/CSS with a little JavaScript for
> maximum portability and familiarity.

I'm afraid I lean in the opposite direction.  We are by no means a special
snowflake such that we need to do this from scratch.  One of the aims here is
to be able to take away the need for writing HTML/CSS, not make it an upfront
requirement.

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.

> Meanwhile, I committed fvwm-web changes yesterday, but those
> changes have not shown up at fvwm.org.
> 
> Jason, what's up?

Probably the same problem with the main FVWM repo; it's wedged.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

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

[Thomas Adam]

On Wed, Mar 23, 2016 at 09:19:18PM -0400, Dan Espen wrote:
> Yep, I'm referring to the web pages.
> I have some CSS based pages at work using themes.
> The themes aren't really important to me, but since
> I doubt GIT is going to give us PHP I think we'll be better off without
> the PHP.

Have a look at this:

https://help.github.com/articles/about-github-pages-and-jekyll/

I think this would be a good way to go, and would reduce the need for us to
potentially write any HTML.

I'm all for using Jekyll in this case!

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: Thoughts about DEVELOPERS.md WAS: [travis-ci - fvwm.git master branch is "protected"]

[Thomas Adam]

On Fri, Mar 25, 2016 at 12:25:09PM +0100, Thomas Funk wrote:
> I think we should. It's better to have such in the documentation so no
> questions appears anymore ;)
> 
> I can add it to the document, no prob.

I've added a few words about this, without making this a rule, which
hopefully people will follow.

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)

Re: travis-ci - fvwm.git master branch is "protected"

[Thomas Adam]

On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote:
> Cool. Would it be possible to stick some unit test framework to it as well?

Sorry, Viktor, I missed this point the last time round.  Yes, that's
possible, and depending on how we decide to write unit tests, it can
just hook into the Travis configuration.  This isn't something I'm
wanting to look at myself just yet, but feel free to do so!

> Is our strategy for handling of branches and pull requests summarized
> anywhere?

I was thinking along the lines of this diff:

https://github.com/fvwmorg/fvwm/commit/f81b2f4d7412813f12b235d8f1914409da0bbae9.patch

Which you can view rendered here:

https://github.com/fvwmorg/fvwm/blob/ta/git-docs/docs/DEVELOPERS.md

What do others think?

-- Thomas Adam

-- 
"Deep in my heart I wish I was wrong.  But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)