Re: LyX Forum?
Piero Faustini wrote: How many people use mailing lists? How many use forums? Say 1 lister every 20 forumers? Say 1 to 10 (and I'm fair)? Fairness doesn't enter into it. Either you have data, or you don't. It's not me who says lists are difficoult, it's people. I never used lists before knowing LyX. Perhaps it is possible that generalizing from your own experience is not a productive research methodology in this case. In addition to lyx-users, I subscribe to 9 email lists that I read regularly. In the past, I've subscribed to at least as many others, which I dropped only because their subject areas were no longer as relevant to me. I don't participate regularly in any web forums. Email lists have been in widespread use for decades. They've endured in the face of competitive technologies (Usenet, various web-based systems, instant messaging) because for some purposes, a significant number of users find them superior. Everyone on lyx-users could use a web forum. That we choose not to disproves your claim. In this instance, people have chosen to use the list. It's 10 years since last time I disabled cookies. Hurrah for you. Other people may make different choices. Children use forums. Children who use LyX are welcome to discuss it in forums. So, for that matter, are adults. Some of us don't want to. Lists are difficoult to use comparing to their advantages, so they are for PRO users, almost always have been, and in future I guess they will be ONLY for pro. Utter nonsense. Look at the history of BITNET lists, for example. There is a regrettable tendency, in discussing computer culture, to offer spurious claims about the history of computing as support for arguing that technology X is superior, intuitive, usable, etc. This happens frequently in academia (I've seen a number of scholars make these arguments just in the past year), and even more often in casual argumentation. These arguments are unpersuasive for at least two reasons. First, their historical claims, as I noted, are generally not supported by any data; and they're often contradicted by the data that is available. Second, they endorse the most naive sort of teleological narrative. Even if more users chose technology X in the past, that hardly implies that technology X is better, or that moving to technology X would attract more users, or that any other benefit automatically attaches to technology X. Indeed, this is the entire proposition of LyX: that it's better, at least for some purposes, than Microsoft Word. More people use Word. Children use Word. That doesn't prove Word is better; it doesn't prove Word is easier; it doesn't prove that more people would switch to LyX if it were more like Word. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: LyX Forum?
Piero Faustini wrote: How many people use mailing lists? How many use forums? Say 1 lister every 20 forumers? Say 1 to 10 (and I'm fair)? Fairness doesn't enter into it. Either you have data, or you don't. It's not me who says lists are difficoult, it's people. I never used lists before knowing LyX. Perhaps it is possible that generalizing from your own experience is not a productive research methodology in this case. In addition to lyx-users, I subscribe to 9 email lists that I read regularly. In the past, I've subscribed to at least as many others, which I dropped only because their subject areas were no longer as relevant to me. I don't participate regularly in any web forums. Email lists have been in widespread use for decades. They've endured in the face of competitive technologies (Usenet, various web-based systems, instant messaging) because for some purposes, a significant number of users find them superior. Everyone on lyx-users could use a web forum. That we choose not to disproves your claim. In this instance, people have chosen to use the list. It's 10 years since last time I disabled cookies. Hurrah for you. Other people may make different choices. Children use forums. Children who use LyX are welcome to discuss it in forums. So, for that matter, are adults. Some of us don't want to. Lists are difficoult to use comparing to their advantages, so they are for PRO users, almost always have been, and in future I guess they will be ONLY for pro. Utter nonsense. Look at the history of BITNET lists, for example. There is a regrettable tendency, in discussing computer culture, to offer spurious claims about the history of computing as support for arguing that technology X is superior, intuitive, usable, etc. This happens frequently in academia (I've seen a number of scholars make these arguments just in the past year), and even more often in casual argumentation. These arguments are unpersuasive for at least two reasons. First, their historical claims, as I noted, are generally not supported by any data; and they're often contradicted by the data that is available. Second, they endorse the most naive sort of teleological narrative. Even if more users chose technology X in the past, that hardly implies that technology X is better, or that moving to technology X would attract more users, or that any other benefit automatically attaches to technology X. Indeed, this is the entire proposition of LyX: that it's better, at least for some purposes, than Microsoft Word. More people use Word. Children use Word. That doesn't prove Word is better; it doesn't prove Word is easier; it doesn't prove that more people would switch to LyX if it were more like Word. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: LyX Forum?
Piero Faustini wrote: > > How many people use mailing lists? How many use forums? Say 1 lister every 20 > forumers? Say 1 to 10 (and I'm fair)? Fairness doesn't enter into it. Either you have data, or you don't. > It's not me who says lists are > difficoult, it's people. I never used lists before knowing LyX. Perhaps it is possible that generalizing from your own experience is not a productive research methodology in this case. In addition to lyx-users, I subscribe to 9 email lists that I read regularly. In the past, I've subscribed to at least as many others, which I dropped only because their subject areas were no longer as relevant to me. I don't participate regularly in any web forums. Email lists have been in widespread use for decades. They've endured in the face of competitive technologies (Usenet, various web-based systems, instant messaging) because for some purposes, a significant number of users find them superior. Everyone on lyx-users could use a web forum. That we choose not to disproves your claim. In this instance, people have chosen to use the list. > It's 10 years since last time I disabled cookies. Hurrah for you. Other people may make different choices. > Children use forums. Children who use LyX are welcome to discuss it in forums. So, for that matter, are adults. Some of us don't want to. > Lists are difficoult to use comparing to their advantages, so they are > for PRO users, almost always have been, and in future I guess they will be > ONLY > for pro. Utter nonsense. Look at the history of BITNET lists, for example. There is a regrettable tendency, in discussing computer culture, to offer spurious claims about the history of computing as support for arguing that technology X is superior, "intuitive", "usable", etc. This happens frequently in academia (I've seen a number of scholars make these arguments just in the past year), and even more often in casual argumentation. These arguments are unpersuasive for at least two reasons. First, their historical claims, as I noted, are generally not supported by any data; and they're often contradicted by the data that is available. Second, they endorse the most naive sort of teleological narrative. Even if more users chose technology X in the past, that hardly implies that technology X is better, or that moving to technology X would attract more users, or that any other benefit automatically attaches to technology X. Indeed, this is the entire proposition of LyX: that it's better, at least for some purposes, than Microsoft Word. More people use Word. Children use Word. That doesn't prove Word is better; it doesn't prove Word is easier; it doesn't prove that more people would switch to LyX if it were more like Word. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: Michael Wojcik schrieb: As said this is a bug in LyX I will fix soon. The LyX will automatically translate \ to / etc. I don't see how that's a LyX bug. It is a bug, because \ is not allowed as argument of \href and therefore you get LaTeX errors. Ah, I see. Thanks for that explanation. I was thinking that you were treating LyX's failure to correct a user's error as a bug. -- Michael Wojcik Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: Michael Wojcik schrieb: As said this is a bug in LyX I will fix soon. The LyX will automatically translate \ to / etc. I don't see how that's a LyX bug. It is a bug, because \ is not allowed as argument of \href and therefore you get LaTeX errors. Ah, I see. Thanks for that explanation. I was thinking that you were treating LyX's failure to correct a user's error as a bug. -- Michael Wojcik Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: > Michael Wojcik schrieb: >>> As said this is a bug in LyX I will fix soon. The LyX will automatically >>> translate "\" to "/" etc. >> >> I don't see how that's a LyX bug. > > It is a bug, because \ is not allowed as argument of \href and therefore > you get LaTeX errors. Ah, I see. Thanks for that explanation. I was thinking that you were treating LyX's failure to correct a user's error as a bug. -- Michael Wojcik Rhetoric & Writing, Michigan State University
Re: Hyperlink question: URL syntax
Hubert Christiaen wrote: An URL is composed of - a protocol part ended with ':' ftp:' 'http:' or 'file:' This is the URI scheme. It doesn't necessarily name a protocol. - an address of the server starting with '//' and ending in '/' if the server is the localmachine, one can put 'localhost' or sometimes also just nothing. In this case you have for a file on your machine already 'file:///' ! - then follows the location on the server, which is a bit OS dependent ... The main point, in a case like this, is that the backslash (\) is not a valid URI character, nor is it the URI component separator for a hierarchical path. A valid file-scheme URL must use the forward slash (/). There's nothing OS-dependent about that; it's required by the URI specification. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question
Tao Cumplido wrote: [I wrote:] Is that a bug? file:C:\file.txt is not a valid URL. It should be file:///c:/file.txt. (Actually, even that isn't strictly valid; the c: ought to be c|. But everyone uses and supports c:.) Ok that kind of works. But how am I supposed to know that the directory has to be written like this? There's no mention about this in the Hyperlink-chapter of the manual. Yes, it'd be nice if the LyX documentation discussed file-scheme URLs in the material on hyperlinks. file-scheme URLs give many Windows users trouble, especially because some Microsoft software (notably IE and Explorer) have very sloppy rules for handling them. In theory, you could figure out how to write them by reading the URI specification (IETF STD0066, if memory serves), but it wouldn't be easy. Jukka Korpela has a discussion on file-scheme URLs, including some notes about how to use them on Windows, here: http://www.cs.tut.fi/~jkorpela/fileurl.html Well, the PDF is processed and it works except in Acrobat where Firefox opens with an empty tab, but I guess that's an Acrobat problem?! This could be the result of the stricter same-domain policy in Mozilla-based browsers, combined with something to do with how Acrobat is invoking Firefox. There's a short comment on that on Jukka's page. There's not much that can be done about it; it's a security measure, so it's supposed to be difficult to circumvent. By the way, you can ignore the bit I wrote above about using c| instead of c:. That's no longer allowed by the current URI specification. A strictly-correct file-scheme URL on Windows would use c%3a for the drive letter and colon. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: As said this is a bug in LyX I will fix soon. The LyX will automatically translate \ to / etc. I don't see how that's a LyX bug. Maybe it's a nice feature, though it seems a bit arbitrary. LyX can't also escape reserved characters in the URL, for example, because it can't know if those characters are being used for their reserved purpose. Personally, I'd rather see a documentation update, and not have LyX try to monkey with the URL contents. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question: URL syntax
Hubert Christiaen wrote: An URL is composed of - a protocol part ended with ':' ftp:' 'http:' or 'file:' This is the URI scheme. It doesn't necessarily name a protocol. - an address of the server starting with '//' and ending in '/' if the server is the localmachine, one can put 'localhost' or sometimes also just nothing. In this case you have for a file on your machine already 'file:///' ! - then follows the location on the server, which is a bit OS dependent ... The main point, in a case like this, is that the backslash (\) is not a valid URI character, nor is it the URI component separator for a hierarchical path. A valid file-scheme URL must use the forward slash (/). There's nothing OS-dependent about that; it's required by the URI specification. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question
Tao Cumplido wrote: [I wrote:] Is that a bug? file:C:\file.txt is not a valid URL. It should be file:///c:/file.txt. (Actually, even that isn't strictly valid; the c: ought to be c|. But everyone uses and supports c:.) Ok that kind of works. But how am I supposed to know that the directory has to be written like this? There's no mention about this in the Hyperlink-chapter of the manual. Yes, it'd be nice if the LyX documentation discussed file-scheme URLs in the material on hyperlinks. file-scheme URLs give many Windows users trouble, especially because some Microsoft software (notably IE and Explorer) have very sloppy rules for handling them. In theory, you could figure out how to write them by reading the URI specification (IETF STD0066, if memory serves), but it wouldn't be easy. Jukka Korpela has a discussion on file-scheme URLs, including some notes about how to use them on Windows, here: http://www.cs.tut.fi/~jkorpela/fileurl.html Well, the PDF is processed and it works except in Acrobat where Firefox opens with an empty tab, but I guess that's an Acrobat problem?! This could be the result of the stricter same-domain policy in Mozilla-based browsers, combined with something to do with how Acrobat is invoking Firefox. There's a short comment on that on Jukka's page. There's not much that can be done about it; it's a security measure, so it's supposed to be difficult to circumvent. By the way, you can ignore the bit I wrote above about using c| instead of c:. That's no longer allowed by the current URI specification. A strictly-correct file-scheme URL on Windows would use c%3a for the drive letter and colon. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: As said this is a bug in LyX I will fix soon. The LyX will automatically translate \ to / etc. I don't see how that's a LyX bug. Maybe it's a nice feature, though it seems a bit arbitrary. LyX can't also escape reserved characters in the URL, for example, because it can't know if those characters are being used for their reserved purpose. Personally, I'd rather see a documentation update, and not have LyX try to monkey with the URL contents. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Hyperlink question: URL syntax
Hubert Christiaen wrote: > An URL is composed of > - a protocol part ended with ':' ftp:' 'http:' or 'file:' This is the URI scheme. It doesn't necessarily name a "protocol". > - an address of the server starting with '//' and ending in '/' > if the server is the localmachine, one can put 'localhost' or sometimes > also > just nothing. In this case you have for a file on your machine > already 'file:///' ! > - then follows the location on the server, which is a bit OS dependent ... The main point, in a case like this, is that the backslash (\) is not a valid URI character, nor is it the URI component separator for a hierarchical path. A valid file-scheme URL must use the forward slash (/). There's nothing OS-dependent about that; it's required by the URI specification. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Hyperlink question
Tao Cumplido wrote: >[I wrote:] >> Is that a bug? "file:C:\file.txt" is not a valid URL. It should be >> "file:///c:/file.txt". (Actually, even that isn't strictly valid; the >> "c:" ought to be "c|". But everyone uses and supports "c:".) > > Ok that kind of works. > But how am I supposed to know that the directory has to be written like this? > There's no mention about this in the Hyperlink-chapter of the manual. Yes, it'd be nice if the LyX documentation discussed file-scheme URLs in the material on hyperlinks. file-scheme URLs give many Windows users trouble, especially because some Microsoft software (notably IE and Explorer) have very sloppy rules for handling them. In theory, you could figure out how to write them by reading the URI specification (IETF STD0066, if memory serves), but it wouldn't be easy. Jukka Korpela has a discussion on file-scheme URLs, including some notes about how to use them on Windows, here: http://www.cs.tut.fi/~jkorpela/fileurl.html > Well, the PDF is processed and it works except in Acrobat where > Firefox opens with an empty tab, but I guess that's an Acrobat problem?! This could be the result of the stricter same-domain policy in Mozilla-based browsers, combined with something to do with how Acrobat is invoking Firefox. There's a short comment on that on Jukka's page. There's not much that can be done about it; it's a security measure, so it's supposed to be difficult to circumvent. By the way, you can ignore the bit I wrote above about using "c|" instead of "c:". That's no longer allowed by the current URI specification. A strictly-correct file-scheme URL on Windows would use "c%3a" for the drive letter and colon. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote: > > As said this is a bug in LyX I will fix soon. The LyX will automatically > translate "\" to "/" etc. I don't see how that's a LyX bug. Maybe it's a nice feature, though it seems a bit arbitrary. LyX can't also escape reserved characters in the URL, for example, because it can't know if those characters are being used for their reserved purpose. Personally, I'd rather see a documentation update, and not have LyX try to monkey with the URL contents. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote:
Tao Cumplido schrieb:
I tried to call a simple text file from C:\file.txt but got the
following error:
Text\href{file:C:\file.txt}
{file-link}
The control sequence at the end of the top line
of your error message was never \def'ed.
You found a bug. Can you please report it at bugzilla.lyx.org. I'll try
to fix this as soon as possible.
Is that a bug? file:C:\file.txt is not a valid URL. It should be
file:///c:/file.txt. (Actually, even that isn't strictly valid; the
c: ought to be c|. But everyone uses and supports c:.)
--
Michael Wojcik
Micro Focus
Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote:
Tao Cumplido schrieb:
I tried to call a simple text file from C:\file.txt but got the
following error:
Text\href{file:C:\file.txt}
{file-link}
The control sequence at the end of the top line
of your error message was never \def'ed.
You found a bug. Can you please report it at bugzilla.lyx.org. I'll try
to fix this as soon as possible.
Is that a bug? file:C:\file.txt is not a valid URL. It should be
file:///c:/file.txt. (Actually, even that isn't strictly valid; the
c: ought to be c|. But everyone uses and supports c:.)
--
Michael Wojcik
Micro Focus
Rhetoric Writing, Michigan State University
Re: Hyperlink question
Uwe Stöhr wrote:
> Tao Cumplido schrieb:
>
>> I tried to call a simple text file from C:\file.txt but got the
>> following error:
>>
>> Text\href{file:C:\file.txt}
>> {file-link}
>> The control sequence at the end of the top line
>> of your error message was never \def'ed.
>
> You found a bug. Can you please report it at bugzilla.lyx.org. I'll try
> to fix this as soon as possible.
Is that a bug? "file:C:\file.txt" is not a valid URL. It should be
"file:///c:/file.txt". (Actually, even that isn't strictly valid; the
"c:" ought to be "c|". But everyone uses and supports "c:".)
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
Re: Show pagebreaks in the editor?
rgheck wrote: Vincent van Ravesteijn wrote: I guess he was just not aware that [showing page breaks] is actually not feasible in LyX, as Richard G. Heck kindly explained. What if it would be feasible ? Would it be an added value or is it too the-non-tex-way ? I don't see the value myself. As I said before, in LaTeX (unlike in Word) page breaks can change by the character, as paragraphs are re-broken and floats are repositioned. I guess that makes me think that it isn't even feasible---where do floats appear, vis-a-vis page breaks? But even if it were, it encourages one to think in the wrong terms, at least during the document-creation process. I think even that statement might be a more-generous take on the matter than I would have. There are two ways a LaTeX editor could show page breaks: by guessing, which is likely to be inaccurate (so of little value), not to mention a huge amount of work; or by continually rerunning the toolchain (as with Instant Preview, but greatly aggravated), which is impractical and a waste of resources. More importantly, looking for formatting results such as the location of page breaks from LyX contradicts the entire design philosophy behind late-formatting document production toolchains. There are early-formatting toolchains (so-called WYSIWYG word processors) for those who want early formatting. TeX, LaTeX, and LyX are not designed that way. And, as Richard says, early formatting conflates content and presentation. There's a reason why the Greek rhetors put style and delivery in separate canons: we can only concentrate on so many details at once. As with most things, there are different benefits and costs to early and late rendering. Trying to make one tool do both is likely to produce something with the faults of each. That doesn't mean it's not useful to ask these questions, of course. Understanding why LyX doesn't show page breaks means understanding the principle of late rendering, and hopefully why it's valuable. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Show pagebreaks in the editor?
rgheck wrote: Vincent van Ravesteijn wrote: I guess he was just not aware that [showing page breaks] is actually not feasible in LyX, as Richard G. Heck kindly explained. What if it would be feasible ? Would it be an added value or is it too the-non-tex-way ? I don't see the value myself. As I said before, in LaTeX (unlike in Word) page breaks can change by the character, as paragraphs are re-broken and floats are repositioned. I guess that makes me think that it isn't even feasible---where do floats appear, vis-a-vis page breaks? But even if it were, it encourages one to think in the wrong terms, at least during the document-creation process. I think even that statement might be a more-generous take on the matter than I would have. There are two ways a LaTeX editor could show page breaks: by guessing, which is likely to be inaccurate (so of little value), not to mention a huge amount of work; or by continually rerunning the toolchain (as with Instant Preview, but greatly aggravated), which is impractical and a waste of resources. More importantly, looking for formatting results such as the location of page breaks from LyX contradicts the entire design philosophy behind late-formatting document production toolchains. There are early-formatting toolchains (so-called WYSIWYG word processors) for those who want early formatting. TeX, LaTeX, and LyX are not designed that way. And, as Richard says, early formatting conflates content and presentation. There's a reason why the Greek rhetors put style and delivery in separate canons: we can only concentrate on so many details at once. As with most things, there are different benefits and costs to early and late rendering. Trying to make one tool do both is likely to produce something with the faults of each. That doesn't mean it's not useful to ask these questions, of course. Understanding why LyX doesn't show page breaks means understanding the principle of late rendering, and hopefully why it's valuable. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Show pagebreaks in the editor?
rgheck wrote: > Vincent van Ravesteijn wrote: >>> I guess he was just not aware that [showing page breaks] is actually >>> not feasible in LyX, as Richard G. Heck kindly explained. >>> >> What if it would be feasible ? Would it be an added value or is it too >> the-non-tex-way ? >> > I don't see the value myself. As I said before, in LaTeX (unlike in > Word) page breaks can change by the character, as paragraphs are > re-broken and floats are repositioned. I guess that makes me think that > it isn't even feasible---where do floats appear, vis-a-vis page breaks? > But even if it were, it encourages one to think in the wrong terms, at > least during the document-creation process. I think even that statement might be a more-generous take on the matter than I would have. There are two ways a LaTeX editor could show page breaks: by guessing, which is likely to be inaccurate (so of little value), not to mention a huge amount of work; or by continually rerunning the toolchain (as with Instant Preview, but greatly aggravated), which is impractical and a waste of resources. More importantly, looking for formatting results such as the location of page breaks from LyX contradicts the entire design philosophy behind late-formatting document production toolchains. There are early-formatting toolchains (so-called WYSIWYG word processors) for those who want early formatting. TeX, LaTeX, and LyX are not designed that way. And, as Richard says, early formatting conflates content and presentation. There's a reason why the Greek rhetors put style and delivery in separate canons: we can only concentrate on so many details at once. As with most things, there are different benefits and costs to early and late rendering. Trying to make one tool do both is likely to produce something with the faults of each. That doesn't mean it's not useful to ask these questions, of course. Understanding why LyX doesn't show page breaks means understanding the principle of late rendering, and hopefully why it's valuable. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Does the version management work under windows?
Paul A. Rubin wrote: Pavel Sanda wrote: ci is a part of rcs. another possibility is subversion. whether there is a possibility to run those creatures under cygwin/windows i haven't slightest clue. Subversion (both server and client) is available for Win XP and higher. As is CVSNT, which includes RCS emulation that ought to work with LyX (though I haven't tried it). There's also at least one port of GNU RCS to Windows, though I'm suspicious of it - back when I last used it, I had what appeared to be file-corruption issues. (It's hard to say, because they weren't reproducible, and it's possible they were caused by something else.) Plus the various Unixy-Windows options, such as Cygwin. For that matter, it's not hard to port RCS to Windows. I ported it to MS-DOS, Windows 3.0, and various versions of OS/2, back in the day. (I also built a distributed version with an OS/400 client. Ah, memories.) But in any case it's easy to get the command-line binaries for all of those version-control systems for Windows. All my Windows machines have both CVSNT and Subversion installed. (I don't bother with Tortoise or other GUI clients; I like to work from the command line for most things. LyX is one of the few exceptions.) -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Does the version management work under windows?
Paul A. Rubin wrote: Pavel Sanda wrote: ci is a part of rcs. another possibility is subversion. whether there is a possibility to run those creatures under cygwin/windows i haven't slightest clue. Subversion (both server and client) is available for Win XP and higher. As is CVSNT, which includes RCS emulation that ought to work with LyX (though I haven't tried it). There's also at least one port of GNU RCS to Windows, though I'm suspicious of it - back when I last used it, I had what appeared to be file-corruption issues. (It's hard to say, because they weren't reproducible, and it's possible they were caused by something else.) Plus the various Unixy-Windows options, such as Cygwin. For that matter, it's not hard to port RCS to Windows. I ported it to MS-DOS, Windows 3.0, and various versions of OS/2, back in the day. (I also built a distributed version with an OS/400 client. Ah, memories.) But in any case it's easy to get the command-line binaries for all of those version-control systems for Windows. All my Windows machines have both CVSNT and Subversion installed. (I don't bother with Tortoise or other GUI clients; I like to work from the command line for most things. LyX is one of the few exceptions.) -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Does the version management work under windows?
Paul A. Rubin wrote: > Pavel Sanda wrote: > >> ci is a part of rcs. another possibility is subversion. >> >> whether there is a possibility to run those creatures under >> cygwin/windows i haven't slightest clue. > > Subversion (both server and client) is available for Win XP and higher. As is CVSNT, which includes RCS emulation that ought to work with LyX (though I haven't tried it). There's also at least one port of GNU RCS to Windows, though I'm suspicious of it - back when I last used it, I had what appeared to be file-corruption issues. (It's hard to say, because they weren't reproducible, and it's possible they were caused by something else.) Plus the various Unixy-Windows options, such as Cygwin. For that matter, it's not hard to port RCS to Windows. I ported it to MS-DOS, Windows 3.0, and various versions of OS/2, back in the day. (I also built a distributed version with an OS/400 client. Ah, memories.) But in any case it's easy to get the command-line binaries for all of those version-control systems for Windows. All my Windows machines have both CVSNT and Subversion installed. (I don't bother with Tortoise or other GUI clients; I like to work from the command line for most things. LyX is one of the few exceptions.) -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. So, at best, that's a period of 4.5 years of API stability. That's close to a joke, especially when taking into account that 3.11 was not usable for any reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. Pretty much around 1990 supposedly the last person died that used plain X. What's plain X? Everyone always ran windows managers on top of X11. That's part of the architecture. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
This has gone on far too long, and I'm not really interested in arguing the point. But some of your response is simply factually incorrect. So, for the record: Andre Poenitz wrote: > On Sun, Nov 23, 2008 at 11:21:27AM -0500, Michael Wojcik wrote: >> Andre Poenitz wrote: >>> On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: >>>> I've worked on many projects that maintained backward compatibility >>>> with new releases of the API, and seen a great many more. >>> Just for my curiosity: Which projects, which scope? >> - Early versions of Windows. The Windows 1.x to Windows 2.0 and >> Windows/286 transition maintained compatibility in the Windows API; >> Windows 1.x applications ran unchanged in the 2.0 family. > > Windows 2.0 was released pretty exactly two years after 1.0, Windows 3.0 > completely broke the API 2 1/2 years later. 16-bit Windows applications continued to run unchanged under Windows 3.0. > So, at best, that's a > period of 4.5 years of "API stability". That's close to a joke, > especially when taking into account that < 3.11 was not usable for any > reasonable practical purpose... Tell that to the hundreds of customers we sold development tools for Windows 2.0. >> - X11R3. The X11 API was layered correctly: as long as the server >> follows the protocol spec, it doesn't matter what it does under the >> covers. I added support for new hardware to the ddx layer; wrote new >> window managers with completely different look-and-feel from the >> standard ones; added extensions to X11 itself. None of that interfered >> with existing clients one bit. > > X11R3: End of 88, X11R4: End of 89. And clients continued to work. And they still work, under X11R5. New releases came out and API compatibility was maintained. Which was my point. > Pretty much around 1990 supposedly the last person died that used plain X. What's "plain X"? Everyone always ran windows managers on top of X11. That's part of the architecture. >> - The 4.3 BSD kernel. Extended multihead support in the console driver >> and wrote some drivers for new hardware. Enhanced the shared memory >> kernel option. Nothing that didn't want to use the new features needed >> to be recompiled. > > Spring (?) 2001 - January 2002. I don't know what those dates are supposed to refer to. BSD 4.3 was released in 1986. BSD 4.4 in 1994. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. ... Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to DLL hell (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no roads. That's not a design failure in the car, nor a mistake on the part of the car's engineers; and neither does it mean that cars are a bad idea. And for the rare application that does, there are other Windows mechanisms
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. I meant just for application which feel that they have to distribute their own version-of-the-day of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. ... Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. Some time back I was disputing the sheer possibility to catch a virus using email. Still ... environments ... came up that made _not catching one_ an art... So things done a while back do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. Mac OS X pretty much shows that _not_ sharing shared libraries on an application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to DLL hell (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. So why go from libstdc++.so.5 to libstdc++.so.6 at all, if incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) Dynamic linking is a good thing. It's worked very well on a number of OSes. Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. I am still pretty convinced that compatibility and progress are fairly incompatible notions when it comes to the development of _usable_ libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. you try to provide everything and the kitchen sink, and end up with design and implementation decisions that need to be re-evaluated from time to time in the presence of new environments. Java and Python, or anything including a GUI comes to mind. I'll offer X11 as a counterexample. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. Ah... should they conform to the Standard or should they be compatible to older versions? To the standard. What is supposed to happen if an existing version does _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. Also: What am I supposed to do in case there is no obvious standard to adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done well before 1998...) around that's uncompilable with todays compilers. Who is to blame here? Should g++ have sticked to 2.95's view of the world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. What is an application supposed to do when it lives in an environment where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no roads. That's not a design failure in the car, nor a mistake on the part of the car's engineers; and neither does it mean that cars are a bad idea. And for the rare application that does, there are other Windows mechanisms
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: >> Completely infeasible on Windows. The loss of shared text would make >> the working set of the typical application mix grossly exceed even the >> absurd amounts of RAM available in typical machines today. The disk >> space problem would be even worse. > > I meant just for application which feel that they have to distribute > their own version-of-the-day > of whatever.dll. There is no reason to do it everywhere of course. Still not feasible, unfortunately, because that includes everything linked with any of the Microsoft C/C++ runtime DLLs. This is the central problem: if you build an application that uses anything in the MS C/C++ library (Microsoft combines the C and C++ standard libraries into a single DLL), which means pretty much anything built with a Microsoft C or C++ compiler, or with the Microsoft Platform SDK, you'll link against some specific version of one or more of the MSVC DLLs. You don't have much choice about which version you get - it depends on what version of the compiler or SDK you have installed, and what updates have been applied to it. For someone else to run that binary, they need that exact same version of the MSVC DLLs. In older versions of the Microsoft toolchain, you could just drop the MSVC DLLs into the same directory as your executable. That's no longer allowed (I think as of Visual Studio 2005 and Platform SDK 6.0). Now they have to be installed into the SxS tree. Microsoft's solution is for every application linked against any MSVC DLL to include the redistributable DLL package for that specific MSVC version as part of their installer package. So it's not the application developers who want you to install a dozen versions of the MSVC runtime. They don't know what versions you already have installed. There's no way to coordinate versions among unrelated applications. People build and distribute binaries, and they carry with them MSVC version requirements. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Tue, Nov 18, 2008 at 03:47:45PM -0500, Michael Wojcik wrote: >> Jean-Marc Lasgouttes wrote: >>> What's wrong with static linking? At least it goes away when the >>> application goes away. >> Completely infeasible on Windows. ... >> Many people have done >> back-of-the-envelope calculations to demonstrate this; I think I did >> some myself, in a post to alt.folklore.computers some time back. > > Some time back I was disputing the sheer possibility to catch a virus > using email. Still ... "environments" ... came up that made _not catching > one_ an art... So "things done a while back" do not count in IT. That's one of the silliest generalizations I've seen in some time. People who ignore the history of IT are doomed to repeat it. Usually poorly. In this specific case, the situation has only gotten worse. However, I have no particular interest in demonstrating it. If you think static linking is feasible on Windows, go ahead and build LyX that way. > Mac OS X pretty much shows that _not_ sharing shared libraries on an > application level is a feasible approach to DLL hell. I wouldn't take anything Apple does as a model. I've used too many Apple products. And avoiding shared code in applications is a solution to "DLL hell" (which is a system administration problem, not an application architecture one) in the same way that walking is a solution to airplane safety. >> It's a lousy idea in any case, as anyone who remembers compiling all >> of BSD 4.2 to switch from local-files resolution to DNS remembers. >> Dynamic linking lets you fix the bug or add the feature in one place. > > So why go from libstdc++.so.5 to libstdc++.so.6 at all, if > incompatible changes can be, as you seem to say, avoided? Because there are many changes that *are* compatible? I'm not a libstdc++ maintainer, so I don't know offhand what the differences in those two releases are; and I'm not going to trawl through the release notes to find out. But it's very rare that a bug fix, or even a new feature, needs to alter an existing API, so there's no reason for it to introduce incompatibility. (Maintaining undefined behavior isn't a compatibility issue. Applications that rely on undefined behavior are broken.) >> Dynamic linking is a good thing. It's worked very well on a number of >> OSes. > > Examples? Most mainframe OSes - all of the MVS and VM family, for example. Also IBM's midrange OSes from S/38 through AS/400 to iOS. Many Unix variants, such as SVR4 and AIX. I believe dynamic linking in VMS wasn't bad, though I only ever looked at it briefly. Worked pretty well on OS/2. For that matter, it often works well on Windows, when DLL management is done properly. >> It would work on Windows if Microsoft could figure out 1) how to >> version properly, and 2) how to maintain backward compatibility. And >> it's not like those are unsolved problems. > > I am happy to have learned now that these problems are solved. They were solved decades ago. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Tue, Nov 18, 2008 at 03:42:52PM -0500, Michael Wojcik wrote: >> Andre Poenitz wrote: >>> On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: >> I've worked on many projects that maintained backward compatibility >> with new releases of the API, and seen a great many more. > > Just for my curiosity: Which projects, which scope? Hmm. Off the top of my head, in roughly chronological order: - Various IBM internal-only projects, such as the E editor. - Early versions of Windows. The Windows 1.x to Windows 2.0 and Windows/286 transition maintained compatibility in the Windows API; Windows 1.x applications ran unchanged in the 2.0 family. - X11R3. The X11 API was layered correctly: as long as the server follows the protocol spec, it doesn't matter what it does under the covers. I added support for new hardware to the ddx layer; wrote new window managers with completely different look-and-feel from the standard ones; added extensions to X11 itself. None of that interfered with existing clients one bit. - The 4.3 BSD kernel. Extended multihead support in the console driver and wrote some drivers for new hardware. Enhanced the shared memory kernel option. Nothing that didn't want to use the new features needed to be recompiled. - A number of Micro Focus commercial products and components thereof: AAI, CSB, CCI, MFCC ... These are commercial APIs used by paying customers to build in-house and ISV commercial applications. Changing them and breaking existing mission-critical applications isn't good for business. But we release updates a few times a year for most of them. Take AAI, for example. AAI 1.0 came out in 1988, and had major new releases for the next 10 years. Typical AAI purchases were in the $10K to $300K range, with yearly maintenance fees. The 1998 release had a feature set probably five times as large as in the 1988 release and ran on a dozen more platforms (from 16-bit Windows to big iron). We still shipped, as one of the demos, the original 1988 demo source - unchanged. The *binaries* from 1988 still ran, unchanged. The 1988 AAI clients and servers interoperated with the 1998 ones, with no user intervention (just a bit of automatic protocol negotiation). Maintaining backward compatibility simply is not that hard. > I am still pretty convinced that "compatibility" and "progress" are > fairly incompatible notions when it comes to the development of _usable_ > libraries. And I'll say that my experience as a professional software developer for 20 years, and as a hobbyist for a number of years prior to that, shows me otherwise. > you try to provide everything and the kitchen sink, and end up with > design and implementation decisions that need to be re-evaluated from > time to time in the presence of new environments. Java and Python, or > anything including a "GUI" comes to mind. I'll offer X11 as a counterexample. >> And in this case, we're talking C and C++ runtimes, which should >> conform to the ISO standard anyway. > > Ah... should they conform to the Standard or should they be compatible to > older versions? To the standard. > What is supposed to happen if an existing version does > _not_ conform to the Standard? Since the standards attempt to codify existing practice, that rarely happens. The only case that comes to mind of an incompatible change in the C standard, between C90 (ISO 9899-1990) and C99, is the choice of return code semantics for snprintf when it was added to the standard. There were two implementations with different semantics; the committee chose the sensible one. The only significant broken implementations by that point were HP's and Microsoft's, and Microsoft's doesn't really count because 1) the canonical name of the function in the Microsoft libraries was _sprintf, an identifier reserved to the implementation, and 2) Microsoft wasn't inclined to follow the standard anyway. > Also: What am I supposed to do in case there is no obvious standard to > adhere to? I have e.g. a few hundred kLOC of pre-1998 C++ code (done > well before 1998...) around that's uncompilable with todays compilers. > Who is to blame here? Should g++ have sticked to 2.95's view of the > world? That's not a dynamic-runtime issue, which is what we were discussing. It's another problem entirely - the overly large and loose definition of the C++ language. >>> In particular that would mean not only source and binary but also >>> behavioural compatibility including keeping buggy behaviour. >> No it doesn't. Undefined behavior is undefined; an application that >> relies on it is broken. > > What is an application supposed to do when it lives in an environment > where only buggy libraries are available? Suck it up? Might as well ask what a car is supposed to do in an environment with no
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: I wonder if disk manufacturers are paying M$ to do this? I've got about 54MB of crap in %windir%\winsxs, with multiple versions of each set of files. Presumably there's no way for Windoze to know that something depending on an older version can use the newer version, so old versions never go away. In fact that's actually the most sensible behaviour since there are only very few cases where a new version indeed can replace an older one without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. In particular that would mean not only source and binary but also behavioural compatibility including keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: What's wrong with static linking? At least it goes away when the application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Andre Poenitz wrote: > On Mon, Nov 17, 2008 at 11:07:05AM -0500, Paul A. Rubin wrote: >> I wonder if disk manufacturers are paying M$ to do this? I've got about >> 54MB of crap in %windir%\winsxs, with multiple versions of each set of >> files. Presumably there's no way for Windoze to know that something >> depending on an older version can use the newer version, so old versions >> never go away. > > In fact that's actually the most sensible behaviour since there are only > very few cases where a new version indeed can replace an older one > without any existing or imagined problem. I respectfully disagree. I've worked on many projects that maintained backward compatibility with new releases of the API, and seen a great many more. And in this case, we're talking C and C++ runtimes, which should conform to the ISO standard anyway. There's no need for them to change every other week. > In particular that would mean > not only source and binary but also behavioural compatibility including > keeping buggy behaviour. No it doesn't. Undefined behavior is undefined; an application that relies on it is broken. And for the rare application that does, there are other Windows mechanisms for tying it to the old version of the DLL. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Jean-Marc Lasgouttes wrote: > > What's wrong with static linking? At least it goes away when the > application goes away. Completely infeasible on Windows. The loss of shared text would make the working set of the typical application mix grossly exceed even the absurd amounts of RAM available in typical machines today. The disk space problem would be even worse. Many people have done back-of-the-envelope calculations to demonstrate this; I think I did some myself, in a post to alt.folklore.computers some time back. It's a lousy idea in any case, as anyone who remembers compiling all of BSD 4.2 to switch from local-files resolution to DNS remembers. Dynamic linking lets you fix the bug or add the feature in one place. We can't have millions of Windows users downloading a refresh of the entire OS every time a bug is fixed in one of the prominent DLLs. Dynamic linking is a good thing. It's worked very well on a number of OSes. It would work on Windows if Microsoft could figure out 1) how to version properly, and 2) how to maintain backward compatibility. And it's not like those are unsolved problems. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: Dominik Waßenhoven schrieb: On the Vista machine, I had no Python installed and the lyx2lyx script failed. I now installed Microsoft's VC++ redistributable package, as suggested by Paul Rubin, and now the lyx2lyx script works. So I think there is a problem with the python.exe and/or python26.dll which are in the bin directory of LyX 1.6. But I also had no Python installed on this Vista machine, only installed LyX using my installer and it worked. I also got feedback that it works for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the Side by Side versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: lyx2lyx script broken (1.6.0 on Vista)
Uwe Stöhr wrote: > Dominik Waßenhoven schrieb: > >> On the Vista machine, I had no Python installed and the lyx2lyx script >> failed. I now installed Microsoft's VC++ redistributable package, as >> suggested by Paul Rubin, and now the lyx2lyx script works. So I think >> there is a problem with the python.exe and/or python26.dll which are in >> the bin directory of LyX 1.6. > > But I also had no Python installed on this Vista machine, only installed > LyX using my installer and it worked. I also got feedback that it works > for others too. It appears the bundled Python requires a particular release of Microsoft's C runtime. There are approximately a zillion releases of the MSVC runtime, all mutually incompatible. For years, Microsoft handled this by changing the name of the MSVC runtime DLLs with each release. More recently, when someone decided it'd be good to have more incompatible runtime versions than would fit in a single MSVC release cycle, they invented the "Side by Side" versioning method, which has the advantages of being a black box, completely different from previous Windows DLL versioning mechanisms, and entirely mysterious, opaque, and frustrating for users. Side-by-Side sticks various releases of the MSVC runtime in directories under %windir%\winsxs. Product installers are supposed to include the MSVC redistributable package for the particular MSVC version they need, which will get installed in Side-by-Side if it's not already present. Probably, people who don't have problems with the minimal Python included with Uwe's installer already have the necessary MSVC redistributable on their machine from some other product installation. The fix would be to include the appropriate MSVC redistributable in Uwe's LyX installer. Note that it may have to be updated any time the Python binaries are updated, since they might be linked with a different MSVC version. Sure makes SVR4 shared object versioning look good, doesn't it? -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
Micha wrote: Writing a letter in lyx is a pain. Eh? I think I've only ever once written a letter in LyX - because I very rarely write letters on the computer - but it was trivial. I just created a new document using the Koma-script letter v2 template and filled in the blanks. The most time-consuming part was scanning my signature so I could have a handwritten signature stamp in the generated PDF. I can't see why writing a letter in Word would be any easier. (As I recall, the last time I did so, it was more work, because I didn't care for any of Word's letter templates, and the default styles weren't quite right for a business letter.) I know some regulars on the list (notably Steve Litt) have advocated Word for short documents. That's fine if it works for them. But I don't see it, myself. But then I've been using markup languages for short documents for a couple of decades (and word processors for only slightly longer), so perhaps I'm simply used to doing so. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
Micha wrote: Writing a letter in lyx is a pain. Eh? I think I've only ever once written a letter in LyX - because I very rarely write letters on the computer - but it was trivial. I just created a new document using the Koma-script letter v2 template and filled in the blanks. The most time-consuming part was scanning my signature so I could have a handwritten signature stamp in the generated PDF. I can't see why writing a letter in Word would be any easier. (As I recall, the last time I did so, it was more work, because I didn't care for any of Word's letter templates, and the default styles weren't quite right for a business letter.) I know some regulars on the list (notably Steve Litt) have advocated Word for short documents. That's fine if it works for them. But I don't see it, myself. But then I've been using markup languages for short documents for a couple of decades (and word processors for only slightly longer), so perhaps I'm simply used to doing so. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
Micha wrote: > > Writing a letter in lyx is a pain. Eh? I think I've only ever once written a letter in LyX - because I very rarely write letters on the computer - but it was trivial. I just created a new document using the Koma-script letter v2 template and filled in the blanks. The most time-consuming part was scanning my signature so I could have a handwritten signature "stamp" in the generated PDF. I can't see why writing a letter in Word would be any easier. (As I recall, the last time I did so, it was more work, because I didn't care for any of Word's letter templates, and the default styles weren't quite right for a business letter.) I know some regulars on the list (notably Steve Litt) have advocated Word for short documents. That's fine if it works for them. But I don't see it, myself. But then I've been using markup languages for short documents for a couple of decades (and word processors for only slightly longer), so perhaps I'm simply used to doing so. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
rgheck wrote: I know a lot of people who use Word, etc, and I don't know a single person who regularly uses styles. I do, but that's largely because I'm ornery, and will do things the Right Way even when the tool discourages it. (I use Word for some work documents, and Open Office for some academic documents, when interop is a requirement.) Students and colleagues send me papers written in Word all the time, and I'm struggling to remember a single time any one of them sent me one that used styles. This subject came up today on techrhet, the technology and rhetoric list, and the prevailing opinion seems to be that, yes, students do not use styles, and that training them to use styles would be a good addition to composition curricula. There's also a fair bit of sentiment that getting away from word processors would be nice, but that's not really an option for general-education composition today. Word processing - and specifically Word - is essentially a general-ed skill in itself, in today's job market. In advanced composition and digital-rhetoric classes, many people are teaching other writing tools. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
rgheck wrote: I know a lot of people who use Word, etc, and I don't know a single person who regularly uses styles. I do, but that's largely because I'm ornery, and will do things the Right Way even when the tool discourages it. (I use Word for some work documents, and Open Office for some academic documents, when interop is a requirement.) Students and colleagues send me papers written in Word all the time, and I'm struggling to remember a single time any one of them sent me one that used styles. This subject came up today on techrhet, the technology and rhetoric list, and the prevailing opinion seems to be that, yes, students do not use styles, and that training them to use styles would be a good addition to composition curricula. There's also a fair bit of sentiment that getting away from word processors would be nice, but that's not really an option for general-education composition today. Word processing - and specifically Word - is essentially a general-ed skill in itself, in today's job market. In advanced composition and digital-rhetoric classes, many people are teaching other writing tools. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: [Fwd: Re: Word processor bashing]
rgheck wrote: > I know a lot of people who use Word, etc, and I don't know a > single person who regularly uses styles. I do, but that's largely because I'm ornery, and will do things the Right Way even when the tool discourages it. (I use Word for some work documents, and Open Office for some academic documents, when interop is a requirement.) > Students and colleagues send me > papers written in Word all the time, and I'm struggling to remember a > single time any one of them sent me one that used styles. This subject came up today on techrhet, the technology and rhetoric list, and the prevailing opinion seems to be that, yes, students do not use styles, and that training them to use styles would be a good addition to composition curricula. There's also a fair bit of sentiment that getting away from word processors would be nice, but that's not really an option for general-education composition today. Word processing - and specifically Word - is essentially a general-ed skill in itself, in today's job market. In advanced composition and digital-rhetoric classes, many people are teaching other writing tools. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Number of documents prepared with LyX? (Was: Frustrated user)
Christian Ridderström wrote: On Wed, 22 Oct 2008, Mike Ressler wrote: I can assure you that LyX has been used to write hundreds of dissertations, theses, and scholarly papers Interesting question... how many such documents have been written using LyX? It appears, from my CVS archives, that I have 16 substantial LyX documents. Not bad, considering I'm often forced to work in Office or OO for interop reasons. And I haven't tried LyX for presentations yet, and those represent a substantial portion of my document output. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Number of documents prepared with LyX? (Was: Frustrated user)
Christian Ridderström wrote: On Wed, 22 Oct 2008, Mike Ressler wrote: I can assure you that LyX has been used to write hundreds of dissertations, theses, and scholarly papers Interesting question... how many such documents have been written using LyX? It appears, from my CVS archives, that I have 16 substantial LyX documents. Not bad, considering I'm often forced to work in Office or OO for interop reasons. And I haven't tried LyX for presentations yet, and those represent a substantial portion of my document output. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Number of documents prepared with LyX? (Was: Frustrated user)
Christian Ridderström wrote: > On Wed, 22 Oct 2008, Mike Ressler wrote: > >> I can assure you that LyX has been used to write hundreds of >> dissertations, theses, and scholarly papers > > Interesting question... how many such documents have been written using > LyX? It appears, from my CVS archives, that I have 16 substantial LyX documents. Not bad, considering I'm often forced to work in Office or OO for interop reasons. And I haven't tried LyX for presentations yet, and those represent a substantial portion of my document output. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Reprinted material
killermike wrote: This is something I have have often wondered about too. For example, if you have a book that was written in 1600 but your copy is a 1976 paperback, what do you put for the date? That's part of the protocol you're using for citing sources, which is a question for you and your editor(s), if any. Some disciplines have particular conventions, which are often formalized in style guides. In MLA style, for example, works are sometimes cited using the actual printing date, with the first-publication date in square brackets: 1976 [1600]. That's because minute details of the text are sometimes important in literary and textual studies, and typographical errors, spelling changes, and the like can be introduced in subsequent printings. (Sometimes there are even bigger changes; James apparently rewrote the ending to _Daisy Miller_ at some point between editions, so there are two versions of the novel out there.) What it comes down to, though, is that there are no natural rules for how to cite anything. There are more-or-less arbitrary rules created by various publishing houses, professional organizations, journals, editors, and the like; there are guidelines and style guides; there are the whims of individuals. So no one can give you a universal rule for a specific sort of citation. It depends on who's going to be reading it, and what they'll accept. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Reprinted material
killermike wrote: This is something I have have often wondered about too. For example, if you have a book that was written in 1600 but your copy is a 1976 paperback, what do you put for the date? That's part of the protocol you're using for citing sources, which is a question for you and your editor(s), if any. Some disciplines have particular conventions, which are often formalized in style guides. In MLA style, for example, works are sometimes cited using the actual printing date, with the first-publication date in square brackets: 1976 [1600]. That's because minute details of the text are sometimes important in literary and textual studies, and typographical errors, spelling changes, and the like can be introduced in subsequent printings. (Sometimes there are even bigger changes; James apparently rewrote the ending to _Daisy Miller_ at some point between editions, so there are two versions of the novel out there.) What it comes down to, though, is that there are no natural rules for how to cite anything. There are more-or-less arbitrary rules created by various publishing houses, professional organizations, journals, editors, and the like; there are guidelines and style guides; there are the whims of individuals. So no one can give you a universal rule for a specific sort of citation. It depends on who's going to be reading it, and what they'll accept. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Reprinted material
killermike wrote: >> > This is something I have have often wondered about too. For example, if > you have a book that was written in 1600 but your copy is a 1976 > paperback, what do you put for the date? That's part of the protocol you're using for citing sources, which is a question for you and your editor(s), if any. Some disciplines have particular conventions, which are often formalized in style guides. In MLA style, for example, works are sometimes cited using the actual printing date, with the first-publication date in square brackets: "1976 [1600]". That's because minute details of the text are sometimes important in literary and textual studies, and typographical errors, spelling changes, and the like can be introduced in subsequent printings. (Sometimes there are even bigger changes; James apparently rewrote the ending to _Daisy Miller_ at some point between editions, so there are two versions of the novel out there.) What it comes down to, though, is that there are no natural rules for how to cite anything. There are more-or-less arbitrary rules created by various publishing houses, professional organizations, journals, editors, and the like; there are guidelines and style guides; there are the whims of individuals. So no one can give you a universal rule for a specific sort of citation. It depends on who's going to be reading it, and what they'll accept. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: math tool
Christian Ridderström wrote: On Fri, 8 Aug 2008, Abdelrazak Younes wrote: [Sometimes I don't get Abdel's messages to the list. I only see them when someone quotes them, as Christian did here. I don't know why. They're not getting caught by Thunderbird's spam filter; and it only happens to some of them. I haven't noticed any other missing lyx-users messages. Odd.] I don't think you missed anything. And we'd be delighted to have you within the development team :-) I keep meaning to pull the sources from Subversion and take a look. I've just been too busy between work and this part-time Master's degree I'm working on. What I really *should* do is send in a financial contribution. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: math tool
Christian Ridderström wrote: On Fri, 8 Aug 2008, Abdelrazak Younes wrote: [Sometimes I don't get Abdel's messages to the list. I only see them when someone quotes them, as Christian did here. I don't know why. They're not getting caught by Thunderbird's spam filter; and it only happens to some of them. I haven't noticed any other missing lyx-users messages. Odd.] I don't think you missed anything. And we'd be delighted to have you within the development team :-) I keep meaning to pull the sources from Subversion and take a look. I've just been too busy between work and this part-time Master's degree I'm working on. What I really *should* do is send in a financial contribution. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: math tool
Christian Ridderström wrote: On Fri, 8 Aug 2008, Abdelrazak Younes wrote: [Sometimes I don't get Abdel's messages to the list. I only see them when someone quotes them, as Christian did here. I don't know why. They're not getting caught by Thunderbird's spam filter; and it only happens to some of them. I haven't noticed any other missing lyx-users messages. Odd.] I don't think you missed anything. And we'd be delighted to have you within the development team :-) I keep meaning to pull the sources from Subversion and take a look. I've just been too busy between work and this part-time Master's degree I'm working on. What I really *should* do is send in a financial contribution. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: math tool
rgheck wrote: nisa wrote: how math editor is implemented in lyx? how does it automatically format text? pls tell the technical aspects of it in the coding part etc Why would you think this was simple enough to be explained in an email message? Now that part is complicated! You can see it here: http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed. Not many of us developers even understand it, though. Andre Poenitz is the master I just browsed a bit of it, and it doesn't look all that hard. Basically a polymorphic model/view system where each sort of math object knows how to render itself, which is what I'd expect. That's a standard idiom - it's the main example in the original Gang of Four _Design Patterns_ book, after all. I'd think someone with decent C++ knowledge and a reasonable grasp of software design could figure the architecture out with a little browsing through the code and perhaps following a few examples through the debugger. (Which is not to say anything against any of the LyX developers - I don't see why anyone would do that unless they need to know how it works. I'm sure all of you *could* if you felt the need.) Or am I missing something? I only read through four or five source files. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: math tool
rgheck wrote: nisa wrote: how math editor is implemented in lyx? how does it automatically format text? pls tell the technical aspects of it in the coding part etc Why would you think this was simple enough to be explained in an email message? Now that part is complicated! You can see it here: http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed. Not many of us developers even understand it, though. Andre Poenitz is the master I just browsed a bit of it, and it doesn't look all that hard. Basically a polymorphic model/view system where each sort of math object knows how to render itself, which is what I'd expect. That's a standard idiom - it's the main example in the original Gang of Four _Design Patterns_ book, after all. I'd think someone with decent C++ knowledge and a reasonable grasp of software design could figure the architecture out with a little browsing through the code and perhaps following a few examples through the debugger. (Which is not to say anything against any of the LyX developers - I don't see why anyone would do that unless they need to know how it works. I'm sure all of you *could* if you felt the need.) Or am I missing something? I only read through four or five source files. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: math tool
rgheck wrote: nisa wrote: how math editor is implemented in lyx? how does it automatically format text? pls tell the technical aspects of it in the coding part etc Why would you think this was simple enough to be explained in an email message? Now that part is complicated! You can see it here: http://www.lyx.org/trac/browser/lyx-devel/trunk/src/mathed. Not many of us developers even understand it, though. Andre Poenitz is the master I just browsed a bit of it, and it doesn't look all that hard. Basically a polymorphic model/view system where each sort of math object knows how to render itself, which is what I'd expect. That's a standard idiom - it's the main example in the original Gang of Four _Design Patterns_ book, after all. I'd think someone with decent C++ knowledge and a reasonable grasp of software design could figure the architecture out with a little browsing through the code and perhaps following a few examples through the debugger. (Which is not to say anything against any of the LyX developers - I don't see why anyone would do that unless they need to know how it works. I'm sure all of you *could* if you felt the need.) Or am I missing something? I only read through four or five source files. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Interesting thread on Slashdot
Dotan Cohen wrote: Is LyX only good for writing books, then? It's good for whatever works for you. Steve Litt likes LyX for writing books. As he's noted before on the list, he doesn't like it for writing short documents, such as letters. When he uses LyX to write a book, he writes the frontmatter in ERT (LaTeX). That's one way of using LyX, and it seems to work well for him. I use LyX for various types of scholarly articles - including some genres, like collage, that are fairly unlike the typical article. I also use it sometimes for writing short documents such as letters. I like LyX for letters because I find it quick and easy and I don't feel the need to fine-tune the output; I'm happy to let the LaTeX class I'm using do that. Sometimes when I drive a nail I use a hammer; sometimes I use a nailgun; sometimes I use an air-powered palm nailer. I have different hammers for different tasks. Sometimes I use a hammer where someone else might use a nailgun. You want to use an appropriate tool, but that still leaves you with choices, and different users prefer different trade-offs. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Interesting thread on Slashdot
Dotan Cohen wrote: Is LyX only good for writing books, then? It's good for whatever works for you. Steve Litt likes LyX for writing books. As he's noted before on the list, he doesn't like it for writing short documents, such as letters. When he uses LyX to write a book, he writes the frontmatter in ERT (LaTeX). That's one way of using LyX, and it seems to work well for him. I use LyX for various types of scholarly articles - including some genres, like collage, that are fairly unlike the typical article. I also use it sometimes for writing short documents such as letters. I like LyX for letters because I find it quick and easy and I don't feel the need to fine-tune the output; I'm happy to let the LaTeX class I'm using do that. Sometimes when I drive a nail I use a hammer; sometimes I use a nailgun; sometimes I use an air-powered palm nailer. I have different hammers for different tasks. Sometimes I use a hammer where someone else might use a nailgun. You want to use an appropriate tool, but that still leaves you with choices, and different users prefer different trade-offs. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Interesting thread on Slashdot
Dotan Cohen wrote: Is LyX only good for writing books, then? It's good for whatever works for you. Steve Litt likes LyX for writing books. As he's noted before on the list, he doesn't like it for writing short documents, such as letters. When he uses LyX to write a book, he writes the frontmatter in ERT (LaTeX). That's one way of using LyX, and it seems to work well for him. I use LyX for various types of scholarly articles - including some genres, like collage, that are fairly unlike the typical article. I also use it sometimes for writing short documents such as letters. I like LyX for letters because I find it quick and easy and I don't feel the need to fine-tune the output; I'm happy to let the LaTeX class I'm using do that. Sometimes when I drive a nail I use a hammer; sometimes I use a nailgun; sometimes I use an air-powered palm nailer. I have different hammers for different tasks. Sometimes I use a hammer where someone else might use a nailgun. You want to use an appropriate tool, but that still leaves you with choices, and different users prefer different trade-offs. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Manveru wrote: Have you ever merge XML? I tried - it is horrible work. It depends entirely on how the XML document is formatted. There's nothing that prevents XML with sensible line breaks, for example. I keep lots of XHTML documents in CVS. They're well-formatted, so merging works just fine. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: Trouble is, replacing \begin..\end with .../ is a hack. LyX developers have defined LyX native format as \begin always is the first character on a line. There's no such requirement in XML, and if we require it, that's a hack. If we don't require it, LyX-XML parsing becomes a whole new level of difficulty. It's not hard at all, with an XML parser. Actually, putting all XML elements on their own lines, with or without leading whitespace, can be done with a DFA (or anything equivalent, such as a regular expression); you don't even need a full-strength parser. If you want elements all on their own lines, pre-processing with a quick sed script would do that for you. I'm a toolsmith myself, and I write lots of tools, in lots of languages, for pre- and post-processing various file formats. I don't expect the switch to XML to cause me any problems, and to be honest I'm a bit puzzled by all the worrying. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Manveru wrote: Have you ever merge XML? I tried - it is horrible work. It depends entirely on how the XML document is formatted. There's nothing that prevents XML with sensible line breaks, for example. I keep lots of XHTML documents in CVS. They're well-formatted, so merging works just fine. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: Trouble is, replacing \begin..\end with .../ is a hack. LyX developers have defined LyX native format as \begin always is the first character on a line. There's no such requirement in XML, and if we require it, that's a hack. If we don't require it, LyX-XML parsing becomes a whole new level of difficulty. It's not hard at all, with an XML parser. Actually, putting all XML elements on their own lines, with or without leading whitespace, can be done with a DFA (or anything equivalent, such as a regular expression); you don't even need a full-strength parser. If you want elements all on their own lines, pre-processing with a quick sed script would do that for you. I'm a toolsmith myself, and I write lots of tools, in lots of languages, for pre- and post-processing various file formats. I don't expect the switch to XML to cause me any problems, and to be honest I'm a bit puzzled by all the worrying. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Manveru wrote: Have you ever merge XML? I tried - it is horrible work. It depends entirely on how the XML document is formatted. There's nothing that prevents XML with sensible line breaks, for example. I keep lots of XHTML documents in CVS. They're well-formatted, so merging works just fine. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Progress on the MS Word to LyX conversion (xml)
Steve Litt wrote: Trouble is, replacing \begin..\end with <>... is a hack. LyX developers have defined LyX native format as \begin always is the first character on a line. There's no such requirement in XML, and if we require it, that's a hack. If we don't require it, LyX-XML parsing becomes a whole new level of difficulty. It's not hard at all, with an XML parser. Actually, putting all XML elements on their own lines, with or without leading whitespace, can be done with a DFA (or anything equivalent, such as a regular expression); you don't even need a full-strength parser. If you want elements all on their own lines, pre-processing with a quick sed script would do that for you. I'm a toolsmith myself, and I write lots of tools, in lots of languages, for pre- and post-processing various file formats. I don't expect the switch to XML to cause me any problems, and to be honest I'm a bit puzzled by all the worrying. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: Footnote without numbering (new)
Jean-Marc Lasgouttes wrote: Adrian Peter [EMAIL PROTECTED] writes: Thank you for the suggestion but unfortunately I really need to put a footnote without a symbol or anything. I am trying to use Lyx for my thesis. Our college requires that if any of the chapters has already appeared as a publication that we need to list it on the first page of the chapter as a footnote. I thought that in such cases a numbered footnote was appended to the title of the chapter. The style Adrian describes seems to be relatively common in the US, for various purposes. For example, many journals set text formatted as a footnote with no number (often on the first or last page of an article), with material such as previous publication, requirements for reproduction, acknowledgments, and so on. A couple of examples I have to hand are _Critical Inquiry_ and _Communications of the ACM_. So I'm not surprised that Adrian's college uses the same convention when documenting prior publication. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Footnote without numbering (new)
Jean-Marc Lasgouttes wrote: Adrian Peter [EMAIL PROTECTED] writes: Thank you for the suggestion but unfortunately I really need to put a footnote without a symbol or anything. I am trying to use Lyx for my thesis. Our college requires that if any of the chapters has already appeared as a publication that we need to list it on the first page of the chapter as a footnote. I thought that in such cases a numbered footnote was appended to the title of the chapter. The style Adrian describes seems to be relatively common in the US, for various purposes. For example, many journals set text formatted as a footnote with no number (often on the first or last page of an article), with material such as previous publication, requirements for reproduction, acknowledgments, and so on. A couple of examples I have to hand are _Critical Inquiry_ and _Communications of the ACM_. So I'm not surprised that Adrian's college uses the same convention when documenting prior publication. -- Michael Wojcik Micro Focus Rhetoric Writing, Michigan State University
Re: Footnote without numbering (new)
Jean-Marc Lasgouttes wrote: Adrian Peter <[EMAIL PROTECTED]> writes: Thank you for the suggestion but unfortunately I really need to put a footnote without a symbol or anything. I am trying to use Lyx for my thesis. Our college requires that if any of the chapters has already appeared as a publication that we need to list it on the first page of the chapter as a footnote. I thought that in such cases a numbered footnote was appended to the title of the chapter. The style Adrian describes seems to be relatively common in the US, for various purposes. For example, many journals set text formatted as a footnote with no number (often on the first or last page of an article), with material such as previous publication, requirements for reproduction, acknowledgments, and so on. A couple of examples I have to hand are _Critical Inquiry_ and _Communications of the ACM_. So I'm not surprised that Adrian's college uses the same convention when documenting prior publication. -- Michael Wojcik Micro Focus Rhetoric & Writing, Michigan State University
Re: question about lyx
Rich Shepard wrote: On Mon, 31 Mar 2008, Michael Wojcik wrote: It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. That's because xhtml has moved toward separation of content and formatting, just as LaTeX/LyX does. The xhtml has the content and the css has the formatting. Yes, HTML is finally catching up with proper document markup languages like CTSS RUNOFF (invented in 1964) in that regard. Of course, RUNOFF led to Multics runoff, which led to Unix roff. As an undergrad I wrote papers in roff (with I think the misc macro package) and printed them with troff on an IBM mainframe laser printer. This was the late 1980s, and the results were pretty slick. RUNOFF also seems to have led to IBM SCRIPT. Partly in response to difficulties with the RUNOFF family, Goldfarb, Mosher, and Lorie invented GML (also IBM, in 1969), which became SGML, which spawned HTML, then XML, then XHTML... Those who forget the separation of presentation and content are doomed to reinvent it. But only after inculcating bad habits in most of their users. (Note the Wikipedia pages for SCRIPT and GML are a bit confused, as usual, about the history and chronology. Goldfarb's own Personal Recollection[1] is a better source of information.) Meanwhile, Knuth created TeX beginning in the late 1970s (the first TeXbook edition was 1982, I think), independently of the RUNOFF / GML families - though I'm sure he was aware of them. TeX of course incorporated significant features that other markup languages did not, such as the sophisticated layout algorithms and extensive support for typesetting mathematical notation. But it too separated content and presentation. For that matter, HTML originally tried to separate content and presentation to some extent. That's why it had strong and em[phasis] tags, for example - presentation was the task of the user agent. But authors wanted more control over presentation (often for no good reason), and HTML became a mess of mixed markup. Modern XHTML plus external stylesheets is really the only way to restore a measure of sanity to HTML. [1] http://www.sgmlsource.com/history/roots.htm -- Michael Wojcik
Re: WRB - Observations
William R. Buckley wrote: What really surprises me is the effort various members have expended to encourage me not to help your project. I quite think your efforts are misguided. Well, I suspect this particular issue (the treatment of Windows shortcuts in some of the LyX file-open dialogs, on some systems) has met with resistance for a handful of reasons. Some of the regulars here do not care for Windows, and given the opportunity will voice that opinion. Some pointed out that LyX does not own the file-open dialogs; they're part of Qt, so this might be a Qt bug. And so forth. With most LyX issues, I think you'll find people are interested in at least identifying the problem and searching for a workaround. And the LyX team does release updates quite frequently, with many a bug fixed. Some issues, like this one, prove controversial, but the great majority are accepted by the developers and experienced users. I might point out that my original posting on this particular subject was not in response to you, but to Richard; and it was simply to note that shortcuts are not a feature of the base Windows OS, but of Explorer. (As I pointed out in another note, they're by no means universally supported in any consistent manner by Windows itself.) I did suggest in that note that not following shortcuts to directories in a file-open dialog could be considered a missing feature. And that's been my position all along, which is why I also suggested that it would be worth investigating the discrepant behavior - even suggested that *I* might do so, if I can find the time. I don't think people here are actually trying to discourage you from contributing to the improvement of LyX, and I'm sorry you feel they are. Rather, I'd interpret this thread as a fairly vigorous and opinionated discussion on the issue at hand, its possible underlying causes, and the nature of the problem (a bug? a missing feature? an annoyance? a quirk? in LyX or Qt or Microsoft controls or Windows?) - and the last, though it's not entirely relevant to fixing the problem, does have some weight in evaluating its importance. -- Michael Wojcik
Re: question about lyx
Rich Shepard wrote: On Mon, 31 Mar 2008, Michael Wojcik wrote: It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. That's because xhtml has moved toward separation of content and formatting, just as LaTeX/LyX does. The xhtml has the content and the css has the formatting. Yes, HTML is finally catching up with proper document markup languages like CTSS RUNOFF (invented in 1964) in that regard. Of course, RUNOFF led to Multics runoff, which led to Unix roff. As an undergrad I wrote papers in roff (with I think the misc macro package) and printed them with troff on an IBM mainframe laser printer. This was the late 1980s, and the results were pretty slick. RUNOFF also seems to have led to IBM SCRIPT. Partly in response to difficulties with the RUNOFF family, Goldfarb, Mosher, and Lorie invented GML (also IBM, in 1969), which became SGML, which spawned HTML, then XML, then XHTML... Those who forget the separation of presentation and content are doomed to reinvent it. But only after inculcating bad habits in most of their users. (Note the Wikipedia pages for SCRIPT and GML are a bit confused, as usual, about the history and chronology. Goldfarb's own Personal Recollection[1] is a better source of information.) Meanwhile, Knuth created TeX beginning in the late 1970s (the first TeXbook edition was 1982, I think), independently of the RUNOFF / GML families - though I'm sure he was aware of them. TeX of course incorporated significant features that other markup languages did not, such as the sophisticated layout algorithms and extensive support for typesetting mathematical notation. But it too separated content and presentation. For that matter, HTML originally tried to separate content and presentation to some extent. That's why it had strong and em[phasis] tags, for example - presentation was the task of the user agent. But authors wanted more control over presentation (often for no good reason), and HTML became a mess of mixed markup. Modern XHTML plus external stylesheets is really the only way to restore a measure of sanity to HTML. [1] http://www.sgmlsource.com/history/roots.htm -- Michael Wojcik
Re: WRB - Observations
William R. Buckley wrote: What really surprises me is the effort various members have expended to encourage me not to help your project. I quite think your efforts are misguided. Well, I suspect this particular issue (the treatment of Windows shortcuts in some of the LyX file-open dialogs, on some systems) has met with resistance for a handful of reasons. Some of the regulars here do not care for Windows, and given the opportunity will voice that opinion. Some pointed out that LyX does not own the file-open dialogs; they're part of Qt, so this might be a Qt bug. And so forth. With most LyX issues, I think you'll find people are interested in at least identifying the problem and searching for a workaround. And the LyX team does release updates quite frequently, with many a bug fixed. Some issues, like this one, prove controversial, but the great majority are accepted by the developers and experienced users. I might point out that my original posting on this particular subject was not in response to you, but to Richard; and it was simply to note that shortcuts are not a feature of the base Windows OS, but of Explorer. (As I pointed out in another note, they're by no means universally supported in any consistent manner by Windows itself.) I did suggest in that note that not following shortcuts to directories in a file-open dialog could be considered a missing feature. And that's been my position all along, which is why I also suggested that it would be worth investigating the discrepant behavior - even suggested that *I* might do so, if I can find the time. I don't think people here are actually trying to discourage you from contributing to the improvement of LyX, and I'm sorry you feel they are. Rather, I'd interpret this thread as a fairly vigorous and opinionated discussion on the issue at hand, its possible underlying causes, and the nature of the problem (a bug? a missing feature? an annoyance? a quirk? in LyX or Qt or Microsoft controls or Windows?) - and the last, though it's not entirely relevant to fixing the problem, does have some weight in evaluating its importance. -- Michael Wojcik
Re: question about lyx
Rich Shepard wrote: On Mon, 31 Mar 2008, Michael Wojcik wrote: It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. That's because xhtml has moved toward separation of content and formatting, just as LaTeX/LyX does. The xhtml has the content and the css has the formatting. Yes, HTML is finally catching up with proper document markup languages like CTSS RUNOFF (invented in 1964) in that regard. Of course, RUNOFF led to Multics runoff, which led to Unix roff. As an undergrad I wrote papers in roff (with I think the "misc" macro package) and printed them with troff on an IBM mainframe laser printer. This was the late 1980s, and the results were pretty slick. RUNOFF also seems to have led to IBM SCRIPT. Partly in response to difficulties with the RUNOFF family, Goldfarb, Mosher, and Lorie invented GML (also IBM, in 1969), which became SGML, which spawned HTML, then XML, then XHTML... Those who forget the separation of presentation and content are doomed to reinvent it. But only after inculcating bad habits in most of their users. (Note the Wikipedia pages for SCRIPT and GML are a bit confused, as usual, about the history and chronology. Goldfarb's own "Personal Recollection"[1] is a better source of information.) Meanwhile, Knuth created TeX beginning in the late 1970s (the first TeXbook edition was 1982, I think), independently of the RUNOFF / GML families - though I'm sure he was aware of them. TeX of course incorporated significant features that other markup languages did not, such as the sophisticated layout algorithms and extensive support for typesetting mathematical notation. But it too separated content and presentation. For that matter, HTML originally tried to separate content and presentation to some extent. That's why it had "strong" and "em[phasis]" tags, for example - presentation was the task of the user agent. But authors wanted more control over presentation (often for no good reason), and HTML became a mess of mixed markup. Modern XHTML plus external stylesheets is really the only way to restore a measure of sanity to HTML. [1] http://www.sgmlsource.com/history/roots.htm -- Michael Wojcik
Re: WRB - Observations
William R. Buckley wrote: What really surprises me is the effort various members have expended to encourage me not to help your project. I quite think your efforts are misguided. Well, I suspect this particular issue (the treatment of Windows "shortcuts" in some of the LyX file-open dialogs, on some systems) has met with resistance for a handful of reasons. Some of the regulars here do not care for Windows, and given the opportunity will voice that opinion. Some pointed out that LyX does not own the file-open dialogs; they're part of Qt, so this might be a Qt bug. And so forth. With most LyX issues, I think you'll find people are interested in at least identifying the problem and searching for a workaround. And the LyX team does release updates quite frequently, with many a bug fixed. Some issues, like this one, prove controversial, but the great majority are accepted by the developers and experienced users. I might point out that my original posting on this particular subject was not in response to you, but to Richard; and it was simply to note that shortcuts are not a feature of the base Windows OS, but of Explorer. (As I pointed out in another note, they're by no means universally supported in any consistent manner by Windows itself.) I did suggest in that note that not following shortcuts to directories in a file-open dialog could be considered a missing feature. And that's been my position all along, which is why I also suggested that it would be worth investigating the discrepant behavior - even suggested that *I* might do so, if I can find the time. I don't think people here are actually trying to discourage you from contributing to the improvement of LyX, and I'm sorry you feel they are. Rather, I'd interpret this thread as a fairly vigorous and opinionated discussion on the issue at hand, its possible underlying causes, and the nature of the problem (a bug? a missing feature? an annoyance? a quirk? in LyX or Qt or Microsoft controls or Windows?) - and the last, though it's not entirely relevant to fixing the problem, does have some weight in evaluating its importance. -- Michael Wojcik
Re: question about lyx
Scott White wrote: Date: Sun, 30 Mar 2008 21:38:22 -0400 From: [EMAIL PROTECTED] Scott White wrote: 1) everything is justified. How can I change it to left alignment? Note that LaTeX microspaces, etc, so this looks proper. If you're going to convert to HTML, it probably doesn't matter, since HTML doesn't do justification, does it? Actually I am fairly sure it does. align=justify is valid html tag. It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. The current LyX functionality does not use this tag. I just don't want to be surprised in the future if LyX started to use it. LyX has nothing to do with HTML output. That's produced by a LaTeX renderer that creates HTML (such as htlatex), which is NOT part of LyX. It's crucial to understand what LyX is and is not. LyX does not produce formatted output, except for its own display on the screen. It's an application for producing LaTeX documents and processing them with LaTeX processors - but those processors are part of a LaTeX implementation (or are separate utilities). They aren't part of LyX. This has nothing to do with LyX and everything to do with whatever HTML converter you are using. See ToolsPreferencesConverters, and look for HTML to see what you're using. htlatex $$i is the converter listed, but looking at my directory structure I think it is MiKTeX 2.7. MiKTeX is a LaTeX implementation. It includes htlatex, which is a LaTeX renderer that produces HTML. So what happens here is: 1. You create your document in LyX. 2. You ask LyX to export to HTML. 3. LyX creates a LaTeX document from your document. That will include LaTeX commands for the various options you've set, packages you've included, etc. 4. LyX looks at your converter preferences to find the command line it should use to create HTML. 5. LyX invokes the specified converter (htlatex, for example). 6. The htlatex it finds on your system is (probably) the one supplied with MiKTeX. htlatex will create HTML (and CSS) from the LaTeX document LyX created in step 3. As you can see, what you do in LyX defines the LaTeX document, and that's the input to htlatex. But LyX can only control the final HTML output to the extent that htlatex can be controlled by what's in the LaTeX source (and options on the htlatex command line, if you edit the converter in your LyX preferences). Ultimately, what goes into your HTML output is up to htlatex. LaTeX isn't designed to let you specify exactly how you want your document to look. (It's possible to get very fine-grained control with LaTeX, but it requires a sophisticated understanding of the language.) It's designed to let you worry about content and structure, and let *it* worry about layout. So if you want to specify exactly how your HTML is going to look, I'd suggest one of two things: don't use LaTeX (and LyX), or edit the style sheet (the CSS file) after generating the content. (You can also create a style sheet ahead of time and just substitute it for the one generated by htlatex.) HTML layout is properly done through a stylesheet (using floats, positioning, widths and heights, etc) anyway. -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: Michael Wojcik wrote: I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. LyX uses Qt for its file dialogs, etc, so if this doesn't work correctly, it's got to do with Qt, bugs or otherwise. Agreed, though it would be good to know why people report different behavior in different dialogs, and different behavior on different systems. It's conceivable that something LyX is doing is either triggering a Qt bug in some circumstances (which might be avoidable), or at least causing differing behavior where we could be consistent. If I weren't in the middle of about a zillion other things I'd grab the current sources and take a look. (Maybe over the summer I'll finally get a chance to dig into the LyX source.) Though, pace William, the *real* problem, as I wrote above, is that shortcuts are not part of the Windows OS. They're purely an application-layer artifact. Certainly not all Windows programs handle them the way William would like. (Windows users can try cd'ing across a shortcut in a shell window - no go. cd'ing across junctions works just fine, however, because they *are* first-class filesystem objects.) -- Michael Wojcik
Re: question about lyx
Scott White wrote: Date: Sun, 30 Mar 2008 21:38:22 -0400 From: [EMAIL PROTECTED] Scott White wrote: 1) everything is justified. How can I change it to left alignment? Note that LaTeX microspaces, etc, so this looks proper. If you're going to convert to HTML, it probably doesn't matter, since HTML doesn't do justification, does it? Actually I am fairly sure it does. align=justify is valid html tag. It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. The current LyX functionality does not use this tag. I just don't want to be surprised in the future if LyX started to use it. LyX has nothing to do with HTML output. That's produced by a LaTeX renderer that creates HTML (such as htlatex), which is NOT part of LyX. It's crucial to understand what LyX is and is not. LyX does not produce formatted output, except for its own display on the screen. It's an application for producing LaTeX documents and processing them with LaTeX processors - but those processors are part of a LaTeX implementation (or are separate utilities). They aren't part of LyX. This has nothing to do with LyX and everything to do with whatever HTML converter you are using. See ToolsPreferencesConverters, and look for HTML to see what you're using. htlatex $$i is the converter listed, but looking at my directory structure I think it is MiKTeX 2.7. MiKTeX is a LaTeX implementation. It includes htlatex, which is a LaTeX renderer that produces HTML. So what happens here is: 1. You create your document in LyX. 2. You ask LyX to export to HTML. 3. LyX creates a LaTeX document from your document. That will include LaTeX commands for the various options you've set, packages you've included, etc. 4. LyX looks at your converter preferences to find the command line it should use to create HTML. 5. LyX invokes the specified converter (htlatex, for example). 6. The htlatex it finds on your system is (probably) the one supplied with MiKTeX. htlatex will create HTML (and CSS) from the LaTeX document LyX created in step 3. As you can see, what you do in LyX defines the LaTeX document, and that's the input to htlatex. But LyX can only control the final HTML output to the extent that htlatex can be controlled by what's in the LaTeX source (and options on the htlatex command line, if you edit the converter in your LyX preferences). Ultimately, what goes into your HTML output is up to htlatex. LaTeX isn't designed to let you specify exactly how you want your document to look. (It's possible to get very fine-grained control with LaTeX, but it requires a sophisticated understanding of the language.) It's designed to let you worry about content and structure, and let *it* worry about layout. So if you want to specify exactly how your HTML is going to look, I'd suggest one of two things: don't use LaTeX (and LyX), or edit the style sheet (the CSS file) after generating the content. (You can also create a style sheet ahead of time and just substitute it for the one generated by htlatex.) HTML layout is properly done through a stylesheet (using floats, positioning, widths and heights, etc) anyway. -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: Michael Wojcik wrote: I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. LyX uses Qt for its file dialogs, etc, so if this doesn't work correctly, it's got to do with Qt, bugs or otherwise. Agreed, though it would be good to know why people report different behavior in different dialogs, and different behavior on different systems. It's conceivable that something LyX is doing is either triggering a Qt bug in some circumstances (which might be avoidable), or at least causing differing behavior where we could be consistent. If I weren't in the middle of about a zillion other things I'd grab the current sources and take a look. (Maybe over the summer I'll finally get a chance to dig into the LyX source.) Though, pace William, the *real* problem, as I wrote above, is that shortcuts are not part of the Windows OS. They're purely an application-layer artifact. Certainly not all Windows programs handle them the way William would like. (Windows users can try cd'ing across a shortcut in a shell window - no go. cd'ing across junctions works just fine, however, because they *are* first-class filesystem objects.) -- Michael Wojcik
Re: question about lyx
Scott White wrote: Date: Sun, 30 Mar 2008 21:38:22 -0400 From: [EMAIL PROTECTED] Scott White wrote: 1) everything is justified. How can I change it to left alignment? Note that LaTeX microspaces, etc, so this looks proper. If you're going to convert to HTML, it probably doesn't matter, since HTML doesn't do justification, does it? Actually I am fairly sure it does. align="justify" is valid html tag. It's an attribute, not a tag. And it's deprecated in HTML 4.0, and omitted entirely in XHTML 1.0. The correct way to specify justification in contemporary HTML is with a style. > The current LyX functionality does not use this tag. I just don't want to be surprised in the future if LyX started to use it. LyX has nothing to do with HTML output. That's produced by a LaTeX renderer that creates HTML (such as htlatex), which is NOT part of LyX. It's crucial to understand what LyX is and is not. LyX does not produce formatted output, except for its own display on the screen. It's an application for producing LaTeX documents and processing them with LaTeX processors - but those processors are part of a LaTeX implementation (or are separate utilities). They aren't part of LyX. This has nothing to do with LyX and everything to do with whatever HTML converter you are using. See Tools>Preferences>Converters, and look for HTML to see what you're using. htlatex $$i is the converter listed, but looking at my directory structure I think it is MiKTeX 2.7. MiKTeX is a LaTeX implementation. It includes htlatex, which is a LaTeX renderer that produces HTML. So what happens here is: 1. You create your document in LyX. 2. You ask LyX to export to HTML. 3. LyX creates a LaTeX document from your document. That will include LaTeX commands for the various options you've set, packages you've included, etc. 4. LyX looks at your converter preferences to find the command line it should use to create HTML. 5. LyX invokes the specified converter (htlatex, for example). 6. The htlatex it finds on your system is (probably) the one supplied with MiKTeX. htlatex will create HTML (and CSS) from the LaTeX document LyX created in step 3. As you can see, what you do in LyX defines the LaTeX document, and that's the input to htlatex. But LyX can only control the final HTML output to the extent that htlatex can be controlled by what's in the LaTeX source (and options on the htlatex command line, if you edit the converter in your LyX preferences). Ultimately, what goes into your HTML output is up to htlatex. LaTeX isn't designed to let you specify exactly how you want your document to look. (It's possible to get very fine-grained control with LaTeX, but it requires a sophisticated understanding of the language.) It's designed to let you worry about content and structure, and let *it* worry about layout. So if you want to specify exactly how your HTML is going to look, I'd suggest one of two things: don't use LaTeX (and LyX), or edit the style sheet (the CSS file) after generating the content. (You can also create a style sheet ahead of time and just substitute it for the one generated by htlatex.) HTML layout is properly done through a stylesheet (using floats, positioning, widths and heights, etc) anyway. -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: Michael Wojcik wrote: I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. LyX uses Qt for its file dialogs, etc, so if this doesn't work correctly, it's got to do with Qt, bugs or otherwise. Agreed, though it would be good to know why people report different behavior in different dialogs, and different behavior on different systems. It's conceivable that something LyX is doing is either triggering a Qt bug in some circumstances (which might be avoidable), or at least causing differing behavior where we could be consistent. If I weren't in the middle of about a zillion other things I'd grab the current sources and take a look. (Maybe over the summer I'll finally get a chance to dig into the LyX source.) Though, pace William, the *real* problem, as I wrote above, is that shortcuts are not part of the Windows OS. They're purely an application-layer artifact. Certainly not all Windows programs handle them the way William would like. (Windows users can try cd'ing across a shortcut in a shell window - no go. cd'ing across junctions works just fine, however, because they *are* first-class filesystem objects.) -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: William R. Buckley wrote: I noticed that when trying to browse for the graphic file of a figure inserted into a document via the LyX user interface, and upon trying to utilise a shortcut (as the means to more efficiently select the proper directory that is to be browsed), it happens that LyX copies the shortcut to the Graphics dialog box, instead of opening the directory indicated by the shortcut. I believe this behavior is not what LyX developers intend. Rather, double-clicking on the shortcut should result in an opening of the indicated directory. If so, then this is a bug in Qt for Windows. Soft links work perfectly fine in Linux. I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. The real bug is that Microsoft introduced them in the first place, rather than using a proper filesystem mechanism; and the fix is to avoid them whenever possible, since they're a clumsy, half-implemented hack. The closest analog to soft links in Windows are NTFS junctions, and they work fine with Qt and LyX, as far as I can see. -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: William R. Buckley wrote: I noticed that when trying to browse for the graphic file of a figure inserted into a document via the LyX user interface, and upon trying to utilise a shortcut (as the means to more efficiently select the proper directory that is to be browsed), it happens that LyX copies the shortcut to the Graphics dialog box, instead of opening the directory indicated by the shortcut. I believe this behavior is not what LyX developers intend. Rather, double-clicking on the shortcut should result in an opening of the indicated directory. If so, then this is a bug in Qt for Windows. Soft links work perfectly fine in Linux. I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. The real bug is that Microsoft introduced them in the first place, rather than using a proper filesystem mechanism; and the fix is to avoid them whenever possible, since they're a clumsy, half-implemented hack. The closest analog to soft links in Windows are NTFS junctions, and they work fine with Qt and LyX, as far as I can see. -- Michael Wojcik
Re: WRB - Observations
rgheck wrote: William R. Buckley wrote: I noticed that when trying to browse for the graphic file of a figure inserted into a document via the LyX user interface, and upon trying to utilise a shortcut (as the means to more efficiently select the proper directory that is to be browsed), it happens that LyX copies the shortcut to the Graphics dialog box, instead of opening the directory indicated by the shortcut. I believe this behavior is not what LyX developers intend. Rather, double-clicking on the shortcut should result in an opening of the indicated directory. If so, then this is a bug in Qt for Windows. Soft links work perfectly fine in Linux. I don't think this is a bug in Qt, though arguably it's a missing feature. Shortcuts are not first-class filesystem objects in Windows. They're files that are treated in a special manner by Windows Explorer. The real bug is that Microsoft introduced them in the first place, rather than using a proper filesystem mechanism; and the fix is to avoid them whenever possible, since they're a clumsy, half-implemented hack. The closest analog to soft links in Windows are NTFS junctions, and they work fine with Qt and LyX, as far as I can see. -- Michael Wojcik
Re: feedback on LyX 1.5.1
Uwe Stöhr wrote: William B. King schrieb: Don't particularly want this posted. Don't want replies. Don't want to join any lists. You asked for feedback, and I'm sending to the only address you gave me. What are you talking about? I believe he meant: I have some comments regarding the LyX tutorial. I do not want to join a mailing list. I do not want my comments posted to a mailing list. I am not interested in replies to my comments. However, the only address I have to which I might send my feedback is a mailing list, so that is where I will send it. Alas, I am not particularly good at composing clear email messages. -- Michael Wojcik
Re: Using a network printer
[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Mark Hansel wrote: A restriction to print exclusively through viewers breaks lyx! There are circumstances where printing an exported ps file makes sense (e.g., multiple collated copies, transmit). All of that can be done through viewers. I don't think anyone proposes that we remove the ability to produce .ps-files... Personally, I think it'd be nice to be able to rpint directly from LyX. Out of curiosity, why? I print my documents on a Postscript-capable laser printer, and I've never bothered printing from LyX, because I always review the rendered document in a viewer before printing it. If I need to print an existing document without editing it, I generally have a copy of the final rendered version already available, so why re-render it? And if I don't, I'd just as soon run LyX in batch mode to produce one, than go through the GUI. The question as I see it is if it's worth spending time trying to fix bugs in LyX that are related to printing. (And that are probably specific to the GNU/Linux distribution etc) The worst one isn't: File Print simply doesn't make sense, and that's true on all platforms. The design is broken. LyX supports multiple back ends, and as long as that's true, File Print is at best ambiguous. At worst, it's simply broken, for example if I have pdflatex-specific packages or commands in my document (in the preamble or in ERT). At the very least, the menu item should be named something like Print (Postscript) or Print (dvips). An unqualified Print menu action isn't meaningful for LyX. -- Michael Wojcik
Re: feedback on LyX 1.5.1
Uwe Stöhr wrote: William B. King schrieb: Don't particularly want this posted. Don't want replies. Don't want to join any lists. You asked for feedback, and I'm sending to the only address you gave me. What are you talking about? I believe he meant: I have some comments regarding the LyX tutorial. I do not want to join a mailing list. I do not want my comments posted to a mailing list. I am not interested in replies to my comments. However, the only address I have to which I might send my feedback is a mailing list, so that is where I will send it. Alas, I am not particularly good at composing clear email messages. -- Michael Wojcik
Re: Using a network printer
[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Mark Hansel wrote: A restriction to print exclusively through viewers breaks lyx! There are circumstances where printing an exported ps file makes sense (e.g., multiple collated copies, transmit). All of that can be done through viewers. I don't think anyone proposes that we remove the ability to produce .ps-files... Personally, I think it'd be nice to be able to rpint directly from LyX. Out of curiosity, why? I print my documents on a Postscript-capable laser printer, and I've never bothered printing from LyX, because I always review the rendered document in a viewer before printing it. If I need to print an existing document without editing it, I generally have a copy of the final rendered version already available, so why re-render it? And if I don't, I'd just as soon run LyX in batch mode to produce one, than go through the GUI. The question as I see it is if it's worth spending time trying to fix bugs in LyX that are related to printing. (And that are probably specific to the GNU/Linux distribution etc) The worst one isn't: File Print simply doesn't make sense, and that's true on all platforms. The design is broken. LyX supports multiple back ends, and as long as that's true, File Print is at best ambiguous. At worst, it's simply broken, for example if I have pdflatex-specific packages or commands in my document (in the preamble or in ERT). At the very least, the menu item should be named something like Print (Postscript) or Print (dvips). An unqualified Print menu action isn't meaningful for LyX. -- Michael Wojcik
Re: feedback on LyX 1.5.1
Uwe Stöhr wrote: William B. King schrieb: Don't particularly want this posted. Don't want replies. Don't want to join any lists. You asked for feedback, and I'm sending to the only address you gave me. What are you talking about? I believe he meant: "I have some comments regarding the LyX tutorial. I do not want to join a mailing list. I do not want my comments posted to a mailing list. I am not interested in replies to my comments. However, the only address I have to which I might send my feedback is a mailing list, so that is where I will send it. Alas, I am not particularly good at composing clear email messages." -- Michael Wojcik
Re: Using a network printer
[EMAIL PROTECTED] wrote: On Fri, 21 Mar 2008, Mark Hansel wrote: A restriction to print exclusively through viewers breaks lyx! There are circumstances where printing an exported ps file makes sense (e.g., multiple collated copies, transmit). All of that can be done through viewers. I don't think anyone proposes that we remove the ability to produce .ps-files... Personally, I think it'd be nice to be able to rpint directly from LyX. Out of curiosity, why? I print my documents on a Postscript-capable laser printer, and I've never bothered printing from LyX, because I always review the rendered document in a viewer before printing it. If I need to print an existing document without editing it, I generally have a copy of the final rendered version already available, so why re-render it? And if I don't, I'd just as soon run LyX in batch mode to produce one, than go through the GUI. > The question as I see it is if it's worth spending time trying to fix bugs in LyX that are related to printing. (And that are probably specific to the GNU/Linux distribution etc) The worst one isn't: File > Print simply doesn't make sense, and that's true on all platforms. The design is broken. LyX supports multiple back ends, and as long as that's true, File > Print is at best ambiguous. At worst, it's simply broken, for example if I have pdflatex-specific packages or commands in my document (in the preamble or in ERT). At the very least, the menu item should be named something like "Print (Postscript)" or "Print (dvips)". An unqualified "Print" menu action isn't meaningful for LyX. -- Michael Wojcik
Re: I'm writing a book in VimOutliner
killermike wrote: I'm also a fan of outlining. For the last year or so I have a been using a mind mapping tool called Kdissert The problem with this tool is that editors don't usually accept pitches in graphical form. This means that the process of pitching an article consists of mapping it out and then writing it up, which is rather long-winded. For this reason, like Steve, I've started to wonder if LyX itself can be used for outlining thanks to the new outlining sidebar. I recently wrote a short paper using the Freemind mind-mapping application and LyX. I used Freemind to collect ideas, and to add text (sometimes as much as an entire paragraph) as it occurred to me. (Freemind supports long nodes that contain formatted text, URLs, etc.) Then I used Freemind's XSLT export feature, with a stylesheet I kluged up, to export the map into a LyX document, with the hierarchy of the mind map converted into nested Enumerate environments. That document couldn't be rendered by LaTeX due to the enumeration depth limit, but LyX displayed it properly, and I easily cut and pasted text from it into a Koma-article document that became the final paper. One of these days I'll fix up the stylesheet to use the proper schedule of environments for Koma-article, so that I can go right from the Freemind map to a skeletal LyX document that can then be flushed out. (There's supposed to be a Ruby script that converts Freemind documents to LaTeX, but it's apparently no longer available, and there are advantages to doing it with XSLT: you can export from within Freemind, and you're using an engine designed for this purpose, so you can concentrate on the transformations rather than the implementation.) -- Michael Wojcik
Re: I'm writing a book in VimOutliner
killermike wrote: I'm also a fan of outlining. For the last year or so I have a been using a mind mapping tool called Kdissert The problem with this tool is that editors don't usually accept pitches in graphical form. This means that the process of pitching an article consists of mapping it out and then writing it up, which is rather long-winded. For this reason, like Steve, I've started to wonder if LyX itself can be used for outlining thanks to the new outlining sidebar. I recently wrote a short paper using the Freemind mind-mapping application and LyX. I used Freemind to collect ideas, and to add text (sometimes as much as an entire paragraph) as it occurred to me. (Freemind supports long nodes that contain formatted text, URLs, etc.) Then I used Freemind's XSLT export feature, with a stylesheet I kluged up, to export the map into a LyX document, with the hierarchy of the mind map converted into nested Enumerate environments. That document couldn't be rendered by LaTeX due to the enumeration depth limit, but LyX displayed it properly, and I easily cut and pasted text from it into a Koma-article document that became the final paper. One of these days I'll fix up the stylesheet to use the proper schedule of environments for Koma-article, so that I can go right from the Freemind map to a skeletal LyX document that can then be flushed out. (There's supposed to be a Ruby script that converts Freemind documents to LaTeX, but it's apparently no longer available, and there are advantages to doing it with XSLT: you can export from within Freemind, and you're using an engine designed for this purpose, so you can concentrate on the transformations rather than the implementation.) -- Michael Wojcik
Re: I'm writing a book in VimOutliner
killermike wrote: > > I'm also a fan of outlining. For the last year or so I have a been using > a "mind mapping" tool called Kdissert > > The problem with this tool is that editors don't usually accept pitches in > graphical form. This means that the process of pitching an article consists > of mapping it out and then writing it up, which is rather long-winded. > > For this reason, like Steve, I've started to wonder if LyX itself can be used > for outlining thanks to the new outlining sidebar. I recently wrote a short paper using the Freemind mind-mapping application and LyX. I used Freemind to collect ideas, and to add text (sometimes as much as an entire paragraph) as it occurred to me. (Freemind supports "long nodes" that contain formatted text, URLs, etc.) Then I used Freemind's XSLT export feature, with a stylesheet I kluged up, to export the map into a LyX document, with the hierarchy of the mind map converted into nested Enumerate environments. That document couldn't be rendered by LaTeX due to the enumeration depth limit, but LyX displayed it properly, and I easily cut and pasted text from it into a Koma-article document that became the final paper. One of these days I'll fix up the stylesheet to use the proper schedule of environments for Koma-article, so that I can go right from the Freemind map to a skeletal LyX document that can then be flushed out. (There's supposed to be a Ruby script that converts Freemind documents to LaTeX, but it's apparently no longer available, and there are advantages to doing it with XSLT: you can export from within Freemind, and you're using an engine designed for this purpose, so you can concentrate on the transformations rather than the implementation.) -- Michael Wojcik
Re: Handy word list program for indexing
Steve Litt wrote: fmt -1 tsjustfacts.txt | sed -e s/^[[:space:][:punct:]]*// | sed -e s/[[:space:][:punct:]]*$// | tr [:upper:] [:lower:] | sort | uniq -c | sort -rn The one thing this doesn't do is, upon final sort, sort by count descending but name ascending. Can you think of a way to do that with standard Linux commands? Do you mean you want a sort key composed of the count, sorted numerically and descending, and the name, sorted lexically and ascending? So that words with the same count will be grouped together in the output and, within that group, sorted lexically? Change the final sort to specify a multipart key: sort -k 1nr -k 2 That says sort by a key composed of the first field, taken as numeric, in reverse order; and the second field, using the default options (lexicographic and ascending). This syntax is standard for sort(1) as of SUSv3, by the way - it's not specific to Linux. -- Michael Wojcik
