Re: FVWM 2.6.6: slightly out of sync in CVS/fvwm-web: do not commit anything

On Tue, Mar 15, 2016 at 09:50:31PM +, Thomas Adam wrote: > All, > > Please be aware that I've started the process of releasing FVWM > 2.6.6---but note that the CVS tree is currently wedged with me trying > to tag the release. > > PLEASE DO NOT COMMIT ANYTHING TO CVS >

FVWM code moved to Github

; * Update the release procedure * Put our logo on the front of the landing page for fvwmorg on GH Any questions, do please let me know. Kindly, Thomas Adam [0] http://thread.gmane.org/gmane.comp.window-managers.fvwm.devel/4839/focus=4844 [1] https://github.com/fvwmorg [2] https://github.com/fvwmorg/fvwm

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

; guess we can live without it. Excellent. Then set yourself up with a Github account, and let me know your username, and I'll add you to the fvwmorg and you can do something with the website repository. Note that I'm getting married this weekend and will then be away on honey moon for two weeks. Kindly, Thomas Adam

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

"Thomas Adam" <tho...@fvwm.org> wrote: > On Fri, Mar 25, 2016 at 03:30:03AM +0100, Thomas Funk wrote: > > One point: > > Should we use for development branches a special nomination like > > feature_xy, fix_abc? > > Or only a README which describes

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

"Thomas Adam" <tho...@fvwm.org> wrote: > 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,

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

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 hope

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

On Thu, Mar 24, 2016 at 05:48:55PM +0100, Viktor Griph wrote: > Is our strategy for handling of branches and pull requests summarized > anywhere? I'm working on that. Will put that out for tenure later on today. -- Thomas Adam

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

Hi all, I've to document this formally, but I wanted to let you know of a few options I've enabled for the "master" branch on the main fvwm Git repository. All pushes by default (across all branches) will now have Travis CI ran against them. Travis is a Continuous Integration tool[1] which

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

On 24 March 2016 at 01:19, Dan Espen <des...@verizon.net> wrote: >> Thomas Adam <tho...@fvwm.org> writes: >> See previous paragraph, I do not think this is the right approach at all. > > I don't see the difference. > Right now Jason pulls from CVS to build the

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

might look like using a static HTML generator that github.io accepts, just to prove my points above. I won't be doing that work, however, but if someone does want to give this a go, do please let us know! Kindly, Thomas Adam [1] https://github.com/fvwmorg/fvwm/releases [2] https://gi

Re: FVWM code moved to Github

Hi Jason, On 21 Mar 2016 17:18, "Jason L Tibbitts III" <ti...@math.uh.edu> wrote: > > >>>>> "TA" == Thomas Adam <tho...@fvwm.org> writes: > > TA> Yes, and he's not always around, alas. > > I'm _almost_ always around. But I wa

Re: FVWM code moved to Github

is sort of like github, but > you run it on your own infrastructure. https://pagure.io Thanks indeed! I'm hoping that won't be needed. Github ought to suit us well, once we've ironed out the wrinkles! Kindly, Thomas Adam

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

ee4fc6b8ee3f5c87b8af0 > 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 generat

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

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 wr

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

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

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

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

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

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

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 cur

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

end 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: FVWM code moved to Github

just work---and need to, since there's no replacement for them anyway. Kindly, Thomas Adam

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

wm/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

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

"Thomas Adam" <tho...@fvwm.org> wrote: > 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/

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

on: 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]

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 goo

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

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

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

erhead, and we are then directly able to tweak things as we see fit. Jason, are you OK with this? Kindly, Thomas Ada

RFH: manpages in markdown

u 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

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

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 a

Release versioning and tagging

nce 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

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 ea

Re: Some advices about the new static website

ide the window? ^^ Best, Thomas -- "Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." -- Albert Einstein

Re: Release versioning and tagging

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

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

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

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

. Whilst I appreciate you can still go and find such things, do we actually need fvwm to supprort it? Kindly, Thomas

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

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 c

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [PATCH] Fix FvwmMakeMissingDesktopMenu

fvwm2 early next week, please do chase me. Kindly, Thomas

[fvwmorg/fvwm] f4a498: Update README.md

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

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

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

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

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

[fvwmorg/fvwm]

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

[fvwmorg/fvwm] ea7ed8: Update README.md

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

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

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

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

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

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

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

[fvwmorg/fvwm] ea7ed8: Update README.md

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

Re: [RFC] Splitting the man page

ges. 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/RFC] Xinerama

[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: [PATCH/RFC] Xinerama

ow is on, rather than referencing the width/height of the entire root window. Kindly, Thomas

Re: [RFC] parser branches ready for commit

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: Xinerama

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

Re: [PATCH - parser] (4) updates

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: dv Branches

sier 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

vim plugin has done this, although it hasn't done so in the past. Kindly, Thomas

Re: git access

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

ofunc foo i bar > # hangs: > foo I can maybe foresee this situation arising. Maybe this is worth fixing? Kindly, Thomas

Re: fork-bomb like functions

nvocation) Sounds sensible to me. I say, go for it! Kindly, Thomas

Re: [RFC] parser branches ready for commit

d, 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: Idea: "elastic" move

colour could also be used when a window > border hits the page edge during an interactive move. Say, > if the window is already at the edge and you keep "pushing", > that border uses the "activity" colour to indicate that > something is happening. I think this is definitely going to be required, yes. Kindly, Thomas

Re: Idea: "elastic" move

ncidentally, 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: parser branch

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: parser branch

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 r

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

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

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

lbeit 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: [RFC] Fake a global monitor when RandR is not available.

n a single screen. For reference, I did used to support that, but removed it in commit 6e646e6201051d19dea5fa8e985fcaf884f0d94d Kindly, Thomas

Re: [PATCH - parser] (4) updates

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 functi

Re: [PATCH - parser] (4) updates

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] New parser framework for testing

gt;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] (2) Split off menu documentation to fvwm3menus.1.

t found a good solution to this. I suppose I could ask the asciidoctor maintainers... Kindly, Thomas

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

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.

it makes it harder for me to know what I'm supposed to be tracking, that's all. Kindly, Thomas

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

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: > > > &g

Re: [PATCH] Fix resize calculations.

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: [PATCH] (2) Split off menu documentation to fvwm3menus.1.

made so far. Kindly, Thomas

Re: [RFC] Splitting the man page

. 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: [PATCH] (2) fvwm3styles.1.

g 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] 1/3 Fix and document "bugopts debugrandr".

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

Re: Paging issue

anything until the pointer has moved, even if it is already in the panframe window? Kindly, Thomas

Re: Paging issue

. If enough people don't like it, I'm sure they'll let us know. :) Kindly, Thomas

Re: Paging issue

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: Crashes with monitor_resolve_name

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?

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: [PATCH - parser] (4) updates

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

Re: [PATCH] (6) Various small changes

r 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

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

Re: [RFC] New parser framework for testing

nds: > > 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] parser branches ready for commit

ugging 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: [PATCH - parser] (4) updates

ly. 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] Reject out of range windows for Move and Resize commands.

oing anything else.) Makes sense, Dominik. Will apply. Thanks! Thomas

Re: Paging issue

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: Plans for the NEWS file?

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

<    1   2   3   >