settings.xml is in *nix EOL format on windows

[jmichae3]

should be cr+lf not lf only. try using std::endl instead or \r\n. *nix does not use correct EOL sequence for terminals. correct defacto standard for most every terminal is cr+lf. it only needs to be compatible with the machine it's on.

I turned off the module manager during install and got an xml file like this (edited to include cr's):

settings.zip

after that, I cannot install any modules from anything, and DIR lists are not put into settings.xml

"choose" between ftp and cdrom is not remembered and is not stored in settings.xml.

tabs are not quite kept in settings.xml either, references lost, etc.

[refdoc]

settings.xml is an internal file.

[karlkleinpaste]

more to the point, nearly 50 years ago, unix designers correctly established that "end of line" is a concept, not a hardware function, and chose a single character as the indicator of that concept in typical textual contexts. the displayed manifestation of that concept in both input and output functions sometimes requires a 2-character sequence (\r\n on a dumb terminal), sometimes 1 (\n on devices like some printers that react to \n by performing implicit \r in the process; also, the "cooked" input handling of \r-converted-to-\n in the tty driver), and requires e.g. [p]...[/p] or [br/] or [pre]...[/pre] (pardon my substitutions for angle brackets where github's idiot editor fails to meta-fy my text) when encoded for html environments that will be interpreted by software intelligently filling a text box in a manner entirely unlike any dumb terminal or printer. it is the display environment's problem to recognize the concept -as it occurs- and apply whatever transform is necessary to make it look right for the particular hardware in question at that particular instant. we are not just blindly shoveling a byte stream out the door; we are -always- making a presentation choice suitable to the place where i/o occurs.

fundamentally, microsoft broke this concept 30+ years ago by screwing up the hardware-independent understanding of "end of line" by foolishly tying it to a single, not-universal understanding of how "end of line" actually happens in practice.

with regard to "it only needs to be compatible with the machine it's on," in my environment, my .xiphos directory is shared between my native linux filesystem, a WINE environment which symlinks the pseudo-user in the fake windows filesystem to my native linux filesystem (i do most of my "windows" testing of xiphos under WINE), and a real Win7 VM in which my native linux filesystem is shared from host to guest and to which the Win7 user's .xiphos directory is again linked to my native linux filesystem. It is exactly this shared, common environment where "end of line" as -concept- should have its fullest expression, yet it is exactly here that i find people complaining about how it's wrong to encode it in the proper, correct, hardware-independent manner.

sooner or later, we have to get back to thinking as computer scientists and not just hack engineers, or this kind of now-decades-old incompatibility will haunt us for all future eternity, and our ability to make progress on the underlying constructs of our computer systems will be stunted.

[jmichae3]

take a look at what's in settings.xml, there are 0's in some indices like

<modmgr>
<mod_mgr_source>0</mod_mgr_source>
<mod_mgr_destination>0</mod_mgr_destination>
<mod_mgr_local_source_index>0</mod_mgr_local_source_index>
<mod_mgr_remote_source_index>0</mod_mgr_remote_source_index>
</modmgr>
<fontsize>
<versenum>+0</versenum>
<basefontsize>+0</basefontsize>
</fontsize>
<book>
<module/>
<key/>
<offset>0</offset>
</book>
<keys>
<book>0</book>
<dictionary>Grace</dictionary>
<verse>Romans 8:28</verse>
</keys>

<modules>
<book/>
<comm/>
<devotional/>
<dict/>
<parallels/>
<bible/>
<percomm/>
</modules>

and of course, there's no book 0 (KJV).

[karlkleinpaste]

many, many, many things in computer science index from zero.

the book index of zero is a reference to the beginning of the general book currently displayed. it's a positive forward offset. offset zero means "beginning." it has not a whit to do with the currently displayed bible.

the fontsize indices are additions (or subtractions) from display default.

the mod.mgr references index lists of module sources, again from zero.

trust me, i know what's in settings.xml, and i know why it's all there, including the parts that are historic and no longer exactly relevant but are continued for self-consistency purposes. i maintain the code that puts it there. really. honest. it's all fully understood.

if you have a complaint about how xiphos operates with regard to settings, say so. but this report will now be moved to lockout.