From oneself at gmail.com Thu Jul 9 12:44:29 2020 From: oneself at gmail.com (Eyal Erez) Date: Thu, 9 Jul 2020 15:44:29 +0300 Subject: [xmonad] Single Monitor with Multiple Workspaces Message-ID: Hi, I used to have two monitors and I loved xmonad's ability to switch which workspace was visible on each. That allowed me to set up multiple windows in a workspace and then pop them all in and out as needed. I've since replaced them with a single ultra-wide monitor. I thought it would be amazing, if I can pop in two workspaces side by side on the same monitor and control each independently as if they were on two monitors. Could something like that be possible? -- *Eyal Erez <**oneself at gmail.com* *>* There are 10 types of people, those who know binary and those who don't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Thu Jul 9 13:08:55 2020 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Thu, 9 Jul 2020 15:08:55 +0200 Subject: [xmonad] Change the visibility of windows Message-ID: <20200709130855.GA19288@octa> Hi, is there a way to temporary change the visibility of windows? Sometimes I want to temporary only see two windows of the workspace side by side and afterwards switch back to see all windows. Something like tagging the two windows and then switching to a layout only displaying the tagged. Perhaps even being able to tag windows from different workspaces might be a nice feature. Greetings, Daniel From allbery.b at gmail.com Thu Jul 9 13:36:57 2020 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 9 Jul 2020 09:36:57 -0400 Subject: [xmonad] Single Monitor with Multiple Workspaces In-Reply-To: References: Message-ID: Have you looked at https://github.com/xmonad/xmonad-contrib/blob/master/XMonad/Layout/LayoutScreens.hs ? On 7/9/20, Eyal Erez wrote: > Hi, > > I used to have two monitors and I loved xmonad's ability to switch which > workspace was visible on each. That allowed me to set up multiple windows > in a workspace and then pop them all in and out as needed. I've since > replaced them with a single ultra-wide monitor. I thought it would be > amazing, if I can pop in two workspaces side by side on the same monitor > and control each independently as if they were on two monitors. Could > something like that be possible? > > -- > *Eyal Erez <**oneself at gmail.com* *>* > > There are 10 types of people, those who know binary and those who don't. > -- brandon s allbery kf8nh allbery.b at gmail.com From asjo at koldfront.dk Tue Jul 14 11:43:44 2020 From: asjo at koldfront.dk (=?utf-8?Q?Adam_Sj=C3=B8gren?=) Date: Tue, 14 Jul 2020 13:43:44 +0200 Subject: [xmonad] [PATCH] Update GenerateManpage to new Pandoc API Message-ID: <878sfm9v9r.fsf@tullinup.koldfront.dk> Pandoc 2.8.0 changed the API for templates: · https://pandoc.org/releases.html#pandoc-2.8-2019-11-22 --- Debian unstable just got Pandoc 2.8.1, and the API for templates have changed. This patch is my attempt to adapt GenerateManPage to the change; the generated .1 and .html files look correct to me. util/GenerateManpage.hs | 11 +++++++---- xmonad.cabal | 2 +- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/util/GenerateManpage.hs b/util/GenerateManpage.hs index 7d0cd99..18f8c80 100644 --- a/util/GenerateManpage.hs +++ b/util/GenerateManpage.hs @@ -9,6 +9,7 @@ -- Public License version 2 or later. import Control.Monad.IO.Class (liftIO) +import Control.Error.Util (hush) import Data.Char import Data.List import qualified Data.Text as T @@ -30,14 +31,16 @@ main = do . lines $ markdownSource - manTemplate <- getDefaultTemplate "man" - manBody <- writeMan def { writerTemplate = Just manTemplate } parsed + manTemplate <- getDefaultTemplate (T.pack "man") + compiledManTemplate <- compileTemplate "" manTemplate + manBody <- writeMan def { writerTemplate = hush compiledManTemplate } parsed liftIO $ TIO.writeFile "./man/xmonad.1" $ manBody liftIO $ putStrLn "Documentation created: man/xmonad.1" - htmltemplate <- getDefaultTemplate "html" + htmltemplate <- getDefaultTemplate (T.pack "html") + compiledHtmlTemplate <- compileTemplate "" htmltemplate htmlBody <- writeHtml5String def - { writerTemplate = Just htmltemplate + { writerTemplate = hush compiledHtmlTemplate , writerTableOfContents = True } parsed liftIO $ TIO.writeFile "./man/xmonad.1.html" htmlBody diff --git a/xmonad.cabal b/xmonad.cabal index c35b1ee..3f5810c 100644 --- a/xmonad.cabal +++ b/xmonad.cabal @@ -99,7 +99,7 @@ executable generatemanpage hs-source-dirs: util if flag(generatemanpage) - build-depends: base, pandoc >= 2, regex-posix, text + build-depends: base, pandoc >= 2.8.0, regex-posix, text else buildable: False -- 2.28.0.rc0 -- "there one more pillow I could hold at night Adam Sjøgren but it's breaking my heart it's making me cry" asjo at koldfront.dk From asjo at koldfront.dk Tue Jul 14 12:28:27 2020 From: asjo at koldfront.dk (=?utf-8?Q?Adam_Sj=C3=B8gren?=) Date: Tue, 14 Jul 2020 14:28:27 +0200 Subject: [xmonad] [PATCH] Update GenerateManpage to new Pandoc API References: <878sfm9v9r.fsf@tullinup.koldfront.dk> Message-ID: <87r1te8ems.fsf@tullinup.koldfront.dk> One of the Debian developers maintaining the Pandoc package remarked: > I no longer use xmonad myself, but remember frm when I did that the > biggest frustration was that you'd need a working _development_ > environment, and each time Haskell packages went out of sync (using > Debian unstable), xmonad was one of the last ones to get back in > sync. I imagine that a decoupling from Pandoc might change that. suggesting to change GenerateManPage to use cmark-hs instead: "Output in HTML, groff man, LaTeX, CommonMark, and a custom XML format is supported." · https://github.com/jgm/cmark-hs as cmark-hs does not have the amount of dependencies that Pandoc has (6 vs. 127, in Debian). What do you all think? I will be happy to take a stab at changing GenerateManPage to use cmark instead of Pandoc, if it sounds useful to you. Best regards, Adam -- "Written in water, yeah, it's bound to disappear Adam Sjøgren Written in water, Down the crater of your ear" asjo at koldfront.dk From allbery.b at gmail.com Tue Jul 14 12:32:30 2020 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 14 Jul 2020 08:32:30 -0400 Subject: [xmonad] [PATCH] Update GenerateManpage to new Pandoc API In-Reply-To: <87r1te8ems.fsf@tullinup.koldfront.dk> References: <878sfm9v9r.fsf@tullinup.koldfront.dk> <87r1te8ems.fsf@tullinup.koldfront.dk> Message-ID: This should probably be submitted as a PR. On 7/14/20, Adam Sjøgren wrote: > One of the Debian developers maintaining the Pandoc package remarked: > > > I no longer use xmonad myself, but remember frm when I did that the > > biggest frustration was that you'd need a working _development_ > > environment, and each time Haskell packages went out of sync (using > > Debian unstable), xmonad was one of the last ones to get back in > > sync. I imagine that a decoupling from Pandoc might change that. > > suggesting to change GenerateManPage to use cmark-hs instead: > > "Output in HTML, groff man, LaTeX, CommonMark, and a custom XML format > is supported." > > · https://github.com/jgm/cmark-hs > > as cmark-hs does not have the amount of dependencies that Pandoc has (6 > vs. 127, in Debian). > > What do you all think? > > I will be happy to take a stab at changing GenerateManPage to use cmark > instead of Pandoc, if it sounds useful to you. > > > Best regards, > > Adam > > -- > "Written in water, yeah, it's bound to disappear Adam Sjøgren > Written in water, Down the crater of your ear" asjo at koldfront.dk > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -- brandon s allbery kf8nh allbery.b at gmail.com From asjo at koldfront.dk Tue Jul 14 12:37:59 2020 From: asjo at koldfront.dk (=?utf-8?Q?Adam_Sj=C3=B8gren?=) Date: Tue, 14 Jul 2020 14:37:59 +0200 Subject: [xmonad] [PATCH] Update GenerateManpage to new Pandoc API References: <878sfm9v9r.fsf@tullinup.koldfront.dk> <87r1te8ems.fsf@tullinup.koldfront.dk> Message-ID: <87imeq8e6w.fsf@tullinup.koldfront.dk> Brandon writes: > On 7/14/20, Adam Sjøgren wrote: >> I will be happy to take a stab at changing GenerateManPage to use cmark >> instead of Pandoc, if it sounds useful to you. > This should probably be submitted as a PR. Yes, I just wanted to check if the general consensus is that it would be a worthwhile change, before spending time on it. Best regards, Adam -- "Referring to glorified travelling salesmen Adam Sjøgren as ``road warriors'' is an insult to asjo at koldfront.dk gun-toting nomadic mercenaries everywhere." From asjo at koldfront.dk Thu Jul 16 05:01:36 2020 From: asjo at koldfront.dk (=?utf-8?Q?Adam_Sj=C3=B8gren?=) Date: Thu, 16 Jul 2020 07:01:36 +0200 Subject: [xmonad] using cmark instead of Pandoc in GenerateManPages.hs References: <878sfm9v9r.fsf@tullinup.koldfront.dk> <87r1te8ems.fsf@tullinup.koldfront.dk> Message-ID: <87lfjkt5n3.fsf@tullinup.koldfront.dk> Adam writes: > One of the Debian developers maintaining the Pandoc package remarked: > > > I no longer use xmonad myself, but remember frm when I did that the > > biggest frustration was that you'd need a working _development_ > > environment, and each time Haskell packages went out of sync (using > > Debian unstable), xmonad was one of the last ones to get back in > > sync. I imagine that a decoupling from Pandoc might change that. [...] > I will be happy to take a stab at changing GenerateManPage to use cmark > instead of Pandoc, if it sounds useful to you. I have tried doing so now - Pandoc does more than cmark, so it's more intrusive than I would have liked. The most prominent downside, I think, is the lack of table-of-contents generation. The changes are on the use-cmark branch in this repository: · https://koldfront.dk/git/xmonad/ commit d5b8d08¹ (code, templates) and 9eb731f² (resulting generated pages respectively. Best regards, Adam ¹ https://koldfront.dk/git/xmonad/commit/?id=d5b8d08 ² https://koldfront.dk/git/xmonad/commit/?id=9eb731f -- "A splendid time is guaranteed for all" Adam Sjøgren asjo at koldfront.dk From allbery.b at gmail.com Thu Jul 16 16:04:31 2020 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 16 Jul 2020 12:04:31 -0400 Subject: [xmonad] using cmark instead of Pandoc in GenerateManPages.hs In-Reply-To: <87lfjkt5n3.fsf@tullinup.koldfront.dk> References: <878sfm9v9r.fsf@tullinup.koldfront.dk> <87r1te8ems.fsf@tullinup.koldfront.dk> <87lfjkt5n3.fsf@tullinup.koldfront.dk> Message-ID: Your messages are getting autofiled as spam here, so I wonder if anyone else is seeing them. On 7/16/20, Adam Sjøgren wrote: > Adam writes: > >> One of the Debian developers maintaining the Pandoc package remarked: >> >> > I no longer use xmonad myself, but remember frm when I did that the >> > biggest frustration was that you'd need a working _development_ >> > environment, and each time Haskell packages went out of sync (using >> > Debian unstable), xmonad was one of the last ones to get back in >> > sync. I imagine that a decoupling from Pandoc might change that. > > [...] > >> I will be happy to take a stab at changing GenerateManPage to use cmark >> instead of Pandoc, if it sounds useful to you. > > I have tried doing so now - Pandoc does more than cmark, so it's more > intrusive than I would have liked. > > The most prominent downside, I think, is the lack of table-of-contents > generation. > > The changes are on the use-cmark branch in this repository: > > · https://koldfront.dk/git/xmonad/ > > commit d5b8d08¹ (code, templates) and 9eb731f² (resulting generated > pages respectively. > > > Best regards, > > Adam > > > ¹ https://koldfront.dk/git/xmonad/commit/?id=d5b8d08 > ² https://koldfront.dk/git/xmonad/commit/?id=9eb731f > > -- > "A splendid time is guaranteed for all" Adam Sjøgren > asjo at koldfront.dk > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -- brandon s allbery kf8nh allbery.b at gmail.com