randy at linuxfromscratch.org
Thu Aug 2 14:46:30 PDT 2007
Ag. D. Hatzimanikas wrote these words on 08/02/07 16:28 CST:
> On Thu, Aug 02, at 03:57 Randy McMurchy wrote:
>>> + <para>The <application>rxvt-unicode</application> application, can also run in
>>> + a daemon mode, which make possible to open multiple terminal windows within the
>>> + same process. The <command>urxvtc</command> client connects then to
>>> + <command>urxvtd</command> daemon and requests a new terminal window.</para>
>> Remove the first comma in the first sentence. Then:
>> s/which make/which makes it/
>> Additionally, you can probably remove the whole last sentence as
>> that information is implied in the previous sentence about the
>> daemon. Your call.
> I would prefer to leave it there, as it is important for the reader to
> understand how the daemon system works.
Well, I disagree as it is totally redundant, but it is your call.
To me, it is sort of insulting to the readers to be told how a
Unix daemon works. Most folks at this stage of the game in BLFS
should already know this. Please, though, fix the sentence similar
s/connects then to urxvtd daemon/then connects to the urxvtd daemon/
>>> + <note>
>>> + <para>Use that option with caution. If the daemon crashes, all the
>>> + running processes in the terminal windows are terminated.</para>
>>> + </note>
>> I am getting to where I use fewer and fewer of the note/warning/caution
>> boxes. They do draw attention, however, the readers shouldn't need a gaudy
>> box so that they will read something. Again, your call.
> Ah, this is critical information. I read it in my first patch (with the
> emphasis tags), and I wasn't satisfied. It looks better to me with the
> note tags. I would prefer to leave it that way if you don't mind.
Hmmm... we seem to be butting heads here. I don't think a note
is proper here. But we'll just have to leave it as it is. Know
that using notes/warning/caution boxes is something we are going
to quickly address via the -dev list. I want to get rid of a
whole bunch of them in the book. I mean, a whole bunch.
> Actually it seems like a good idea now that I am thinking about it.
> To do the preliminary work in -dev, and then to commit it.
> I think I will follow that way, if you -all- don't mind. :)
I would prefer to do it the way everyone else does it. Commit and
then provide suggestions via -book. Just seems easier to me, as there
is less review and reading to do.
rmlscsi: [bogomips 1003.26] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 18.104.22.168 i686]
16:37:01 up 16:28, 1 user, load average: 0.03, 0.08, 0.27
More information about the blfs-dev