On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> On Sat, Nov 20, 2021 at 02:15:58PM +, 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
Sending patches is getting out of hand. I believe I had once
write access to the git repo, but it doesn't work anymore
(permission denied when updating). What do I need to do to
reactivate access?
(A quick recap of the procedure involved in getting patches on
master wold help too. I'd also be
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
On Sat, Nov 20, 2021 at 10:24:46PM +, Thomas Adam wrote:
> On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> > On Sat, Nov 20, 2021 at 02:15:58PM +, Thomas Adam wrote:
> > > On Sat, Nov 20, 2021, 14:13 Dominik Vogt wrote:
> > >
> > > > Is Xinerama still useful for anything
On Sat, Nov 20, 2021 at 10:17 PM Dominik Vogt wrote:
>
> Sending patches is getting out of hand. I believe I had once
> write access to the git repo, but it doesn't work anymore
> (permission denied when updating). What do I need to do to
> reactivate access?
>
If you were using a password to
On Sun, Nov 14, 2021 at 10:57 AM Dominik Vogt wrote:
>
> The snapping code is really an unmaintainable mess. Some thoughts
> on how it might be rewritten:
>
Here are some thoughts I have, you can see them in js/snapattract branch.
I have split the three different snapping checks into
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
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
On Sat, Nov 20, 2021 at 04:17:41PM -0700, Jaimos Skriletz wrote:
> On Sun, Nov 14, 2021 at 10:57 AM Dominik Vogt wrote:
> >
> > The snapping code is really an unmaintainable mess. Some thoughts
> > on how it might be rewritten:
> >
>
> Here are some thoughts I have, you can see them in
On Wed, Nov 17, 2021 at 11:20 AM Thomas Adam wrote:
>
> On Wed, Nov 17, 2021 at 02:35:32PM +0100, Dominik Vogt wrote:
> > On Tue, Nov 16, 2021 at 01:36:53AM +0100, Dominik Vogt wrote:
> > > This is the full set of patches for splitting the man page, to be
> > > applied to master.
> >
> > Second
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
And there's still a bug that had been present in the old code:
Assume you have a window on screen and a button bar aligned with
the bottom of the screen. Grab the window at the top border and
move it past the button bar towards the bottom of the screen.
When the top of the window gets close to
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
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 +, Thomas Adam wrote:
> > > On Fri, Nov 19, 2021 at 03:09:35PM +, Thomas Adam wrote:
> > > > On Fri, Nov 19, 2021 at
On Fri, Nov 19, 2021 at 11:35:09PM +, Thomas Adam wrote:
> > 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.
With the doc patch you also
On Sat, Nov 20, 2021 at 11:17:52AM +, Thomas Adam wrote:
> 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?
>
>
Is Xinerama still useful for anything or can we remove it?
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
On Sat, Nov 20, 2021 at 02:15:58PM +, 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
On Sat, Nov 20, 2021 at 03:54:10PM +0100, Dominik Vogt wrote:
> On Sat, Nov 20, 2021 at 02:15:58PM +, 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
A couple of small changes for master:
0001: Makes the code in log.c easiert to read.
0002: Ignore emacs backup files.
0003: Clean up a header file.
0004: Remove the unused dependency from libs/vpacket.h to fvwm/fvwm.h.
0005: Your NEW-PARSEER.md patch without the reindentation.
0006: Remove the -D
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:
addtofunc foo i foo
foo
=> ok
But this is not good:
addtofunc foo
+ i foo
+ i foo
h hangs:
foo
On Sat, Nov 20, 2021 at 08:51:46AM +, Thomas Adam wrote:
> This works,
Please revert this and apply the revert patch in my other message.
> but I am confused as to why it compiles fine for you:
It works on my local branch but not the one in Git because of the
reindentation commit. Can we
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,
23 matches
Mail list logo
