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 to this: 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. -- Randy 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 2.6.14.3 i686] 16:37:01 up 16:28, 1 user, load average: 0.03, 0.08, 0.27 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
