Bug#861124: ITP: elpa-writeroom-mode -- distraction-free writing for Emacs
control: tags -1 -pending
On Tue, Apr 25, 2017 at 01:35:23PM -0400, Antoine Beaupré wrote:
> On 2017-04-25 11:05:57, Nicholas D Steeves wrote:
> > control: pending -1
>
> Just for the record - we usually mark bugs as "tags -1 +pending" when an
> upload is ready in VCS or just uploaded to ftp-master. Not sure the
> above does anything. :)
Haha, yes, I received the failure notice and manually send an email to
control@d. Now I see I need to remove the pending tag because I ran
into what I believe is an upstream issue with the info page (bug filed
upstream)
> > On Tue, Apr 25, 2017 at 08:04:56AM -0400, Antoine Beaupré wrote:
> >> On 2017-04-24 20:37:20, Nicholas D Steeves wrote:
>
> >> > I find it really useful to remove the fringes and margins when going
> >> > from fullscreen to windowed, and to have modeline enabled for
> >> > fullscreen, for battery status, clock, word count, etc, but to have
> >> > these disabled for windowed.
> >>
> >> That seems completely counter-intuitive to me, but I guess if those are
> >> made into separate modes, that should be fine. :)
> >
> > :-) Exactly. My setup is a bit bizarre, but it basically evolved to
> > cope with the transition from a 17" 4:3 screen to a 10" 16:9 netbook,
> > and to get positive feedback from the word count and pressure from the
> > clock while typing way too forcefully while trying to meet deadlines.
> > It would be even more intense with a countdown timer... The premise
> > being that you sit down to write, start writeroom, and the combo of
> > the carrot and stick helps with productivity: an interval of working
> > fast, then a relaxing and/or thinking/planning interval.
>
> Is this similar to the pomodoro technique?
I had to look up pomodoro technique! Yes, I believe it's similar,
especially. From what I read, the original idea behind pomodoro is
different because it insists on the physicality of the timer, winding
the timer, a non-virtual alarm, checking off the intervals on the
piece of paper, etc. I think the main difference is pomodoro rewards
compliance to structured time with breaks, where what I'm thinking
about is more like like gamification or a series of goals. eg: write
X words in Y time, or more abstractly, maintain a rate of Z
words-per-hour by dividing X words by Y time-since-buffer-was-opened.
Everyone works differently but most of the people I know (including
myself) will finish a paper in less time, and to higher quality if the
composition stage is more sprint->break, stretch, do something active,
think about what to do next->loop until word count is met, and then
move on to editing. To me, pomodoro would feel like working in one of
those offices from 1984 or the movie Brazil (1985).
> What do you use for the word count, by the way? I just M-x count-words
> regularly, and since the message bar still shows, that just works...
Traditionally I used wc.el bound to C-c C-c...pretty much the same as
you. Wc in the modeline is now an option, and elpa-wc-mode in sid.
I'm planning to switch to smart-mode-line soon because it can justify
left, centre, or right, so I can finally retire custom modeline.
Elpa-wc-mode + smart-mode-line is a better way to put wc in the lower
right corner of a widescreen monitor where it is visually separate
from the narrow column of text, in dark grey on black where it is
unobtrusive.
If the motion of seeing it update is distracting I'm sure it would be
possible to configure wc-mode to update every N seconds
> >> > One of my other little personal projects is to change the font size
> >> > when going between windowed and fullscreen.
> >>
> >> That seems like a good idea - a separate effect too?
> >
> > I haven't actually done the work for it yet, but I've been wanting to
> > implement it "someday" for years. I think the easiest thing to do,
> > for the purposes of writeroom, would probably be to configure a
> > scaling factor for 'text-scale-adjust as part of the fullscreen hook.
>
> I would make it a completely separate effect - but that's just me. I
> encourage you to file an issue upstream, maybe the author already has
> something in mind for this or even do the work for you. ;)
You can already scale the fonts with C-x C-+ and C-x C-- ;-) I just
want it to be modal. Smaller fonts/larger viewport is better for
overview and editing, but a large font/small viewport helps keep ideas
compact when writing quickly--my preferred default. What do you mean
by separate effect? I think of it as large font for writing long
lines in text mode, and a smaller font with auto-indent enabled when
using a programming mode.
> >> Anwyays, this is all stuff that should be discussed in the upstream
> >> trackers, and not necessarily here. I think we should try to follow
> >> upstream as closely as possible here and get patches merged back
> >> upstream.
> >
> > Merged back, for sure. Is the "discuss it on the BTS first" policy
> > for more users->BTS->maintainers->upstream?
>
> I'm not sure what you mean... In general, Debian welcomes upstream bugs
> in the Debian bugtrackers because we want to support our users. Then
> Debian package maintainers can sort through issues and forward some
> upstream, sometimes fixing it with a patch in the Debian package...
>
> But in general, I believe there is a consensus that we try to follow
> upstream as much as possible.
>From what I can gather it's fairly open; however, for maintainers, I still
wonder where the bulk of discussions should happen. And yes, total
agreement on how it's better to maintain a good relationships with
upstreams!
> > Preliminary packaging is here:
> > ssh://git.debian.org/git/pkg-emacsen/pkg/writeroom-mode.git
>
> Awesome! If you are not yet a Debian member, I encourage you to upload
> a build to mentors.debian.net so that you can get better peer reviews as
> well.
I'm still a DM, so will need a sponsor for the initial upload, but
I'm holding off while I wait for upstream to respond. If appropriate,
would you please take care of the forwarded tag? Upstream url for the
issue can be found here:
https://github.com/joostkremers/writeroom-mode/issues/39
> > I need to email to team to find out what the preferred way of managing
> > things in the VCS during a deep freeze (eg: push tags only, push an
> > experimental branch and keep master's changelog UNRELEASED, etc).
>
> The freeze shouldn't matter in this case: it's a new package, so it
> won't migrate to testing and there's no package in testing to update so
> it's okay to upload to unstable. It's only when there's a version in
> testing that you should avoid uploading to unstable unless it's to fix
> RC bugs, and upload to experimental otherwise.
Thank you for taking the time to explain this :-)
> I use the UNRELEASED suite in the changelog when I upload signed
> packages for public testing so that they don't get uploaded without my
> explicit consent. Otherwise I generally don't use that feature, but
> that's just me.
>
> The emacsen team may indeed has its own peculiar ways of doing things
> and it's good practice to join forces with them.
+1 I got the ok from them to upload to unstable (when the package is
ready) If you're curious about the info page issue the package is
available here:
https://mentors.debian.net/package/writeroom-mode
dget -x https://mentors.debian.net/debian/pool/main/w/writeroom-mode/writeroom-mode_3.6.1-1.dsc
> > Also, I'm not sure what to license debian/* as wrt BSD-3-clause.
>
> I'm not sure what you mean. You need to specify the license of the
> various writeroom-mode files in debian/copyright. Then you chose the
> copyright you prefer for files in debian/* - I usually choose the same
> license as the upstream files, but that's not absolutely mandatory. It
> should be compatible, of course.
Might as well continue to stick with BSD-3-clause then.
Kind regards,
Nicholas
Reply to: