Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, 10 Sep 2021 15:22:30 -0400 rhkra...@gmail.com wrote: > On Friday, September 10, 2021 08:45:19 AM Joe wrote: > > Sadly, much html comes of of MS software, and takes about ten pages > > of markup to include three text lines. > > That may be (or may be a slight exxageration ;-), but in my email > client, if I get a multipart message, the plain text part is > displayed and I see the 3 lines of text -- I don't see the 10 pages > of markup. > > Do you see the ~10 pages of markup? If I need to pick through the html to find something missing from the text, but very often those who use Word as an html email client have never heard of the concept of alternate text. -- Joe
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, Sep 10, 2021 at 03:01:59PM -0400, rhkra...@gmail.com wrote: > On Friday, September 10, 2021 05:20:46 AM Pankaj Jangid wrote: > > writes: > > > (I'm just asking, because I've seen this complaint a couple > > > of times for a well-formed multipart message: personally, I'd > > > be OK with it, but I'd like to know how the consensus is). > > > > I feel that it is okay now to send we formatted multipart messages. As > > long as I am getting text parts (well-formatted), I have no problem. > > +1 Yes, but as we have seen, some MUAs seem to do a miserable job when building the plain text part from the HTML (like forgetting line-ends, which wreaks havoc in source code). I didn't know that. This reduces my tolerance for HTML mail even in the multipart case. The problem there is that the sender is potentially seeing something different from what the receiver is seeing, depending on the quality of the sender's MUA. Not amusing. So multipart might be OK, but expect people trying to help you to get very confused. Cheers - t signature.asc Description: Digital signature
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Friday, September 10, 2021 08:45:19 AM Joe wrote: > Sadly, much html comes of of MS software, and takes about ten pages of > markup to include three text lines. That may be (or may be a slight exxageration ;-), but in my email client, if I get a multipart message, the plain text part is displayed and I see the 3 lines of text -- I don't see the 10 pages of markup. Do you see the ~10 pages of markup? I use an older version of kmail (1.13.7 for kde 4.8.4) and I thought I had to set two relevant options, one to choose to display the plain text part of a multipart message, and the 2nd (less relevant) to choose to compose emails (and replies) in plain text, but, atm, I can't find either of those options.
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Friday, September 10, 2021 05:20:46 AM Pankaj Jangid wrote: > writes: > > (I'm just asking, because I've seen this complaint a couple > > of times for a well-formed multipart message: personally, I'd > > be OK with it, but I'd like to know how the consensus is). > > I feel that it is okay now to send we formatted multipart messages. As > long as I am getting text parts (well-formatted), I have no problem. +1
Re: HTML mail [was: How to improve my question in stackoverflow?]
On 2021-09-10, Charles Curley wrote: > (I also think that if one must use colors, emphasis, etc. as part of > one's writing, then one is not a very good writer. On the other > tentacle, one should not expect good writing from nerds.) > I think there was at least one book--or article or series of articles or maybe even a whole *period* (it was a *style*)--where Tom Wolfe (not the one who went home but found he actually couldn't but the other one) repeatedly used multiple exclamation points at the end of sentences (as well as italics frequently for emphasis). Maybe the exception that proves your rule.
Re: How to improve my question in stackoverflow?
On Fri, 10 Sep 2021 16:17:29 +0200 wrote: > On Fri, Sep 10, 2021 at 07:32:28AM -0400, Greg Wooledge wrote: > > > The absolute worst thing you can do is send HTML (with or without > > text) and then act all arrogant and haughty [...] > > Agreed. Arrogant and haughty is almost always wrong :-D > Unless they are very rich, in which case they are merely eccentric. -- Joe
Re: How to improve my question in stackoverflow?
On Fri, Sep 10, 2021 at 07:32:28AM -0400, Greg Wooledge wrote: > On Fri, Sep 10, 2021 at 08:41:02AM +0200, to...@tuxteam.de wrote: > > The original mail was a passable MIME multipart/alternative > > with a plain text part. I /think/ that is OK, what do others > > think? > > See below. > > On Fri, Sep 10, 2021 at 08:25:05AM +0200, to...@tuxteam.de wrote: > > On Thu, Sep 09, 2021 at 04:27:01PM -0600, William Torrez Corea wrote: > > > *Book.cpp* > > > > > > #include #include #include #include #include > > > #include using namespace std; > > > > The line above looks very strange [...] > What's broken, I'm almost certain, is that this mega-line was > generated by a malformed HTML to text conversion. Yes, confirmed upthread, thanks. > In the general case, sure, it's not *terrible* if someone sends > multi-part text + HTML messages to the mailing list. But this breaks > down in some cases, and causes the text part of the message to be > mangled. Sometimes the readers will be able to discern this, and > figure out what the text was supposed to look like. Other times, we > cannot. > > So, the *best* thing to do would be to send plain text only. Definitely. This case is just evidence to that. > The absolute worst thing you can do is send HTML (with or without text) > and then act all arrogant and haughty [...] Agreed. Arrogant and haughty is almost always wrong :-D Cheers - t signature.asc Description: Digital signature
Re: How to improve my question in stackoverflow?
On Fri, Sep 10, 2021 at 02:16:31PM +0300, IL Ka wrote: > > > > > > Moreover, the included things are files, and by convention they > > have a suffix ".h", for "header". I'd expect the above to look > > rather like > > > > #include [...] > This is true for C, but not for C++. > > With C++ headers could be files or not, so you shouldn't add ".h". > > > The problem is probably "set" written as "Set": C++ is case sensitive. Thanks. For me, a nice way to learn C++ ;-) Cheers - t signature.asc Description: Digital signature
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, Sep 10, 2021 at 11:41:55AM +0200, Linux-Fan wrote: > to...@tuxteam.de writes: [...] > Additionally, in this C++ question thread, the source code was given > in HTML and text parts of the e-mail and while the `#include` > statements were all on separate lines in the HTML, they appear as > one long line in the text part. So definitely one downside of posting HTML and hoping the mailer comes up with a reasonable representation as text (I fell for it). > Btw.: For C++ STL components such as `set` or `string` it is > perfectly fine to not append a `.h`. In fact, it would seem not to > be standards compliant to append the `.h`, cf. > https://stackoverflow.com/questions/15680190 Thanks; Il Ka says the same downthread. I warned that I have very little clue on C++. The problem seems to be that the #include-d stuff is case-sensitive (i.e. "Set" instead of "set"). I defer to the C++ buffs here :) Cheers - t signature.asc Description: Digital signature
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, 10 Sep 2021 06:15:12 -0600 Charles Curley wrote: > On Fri, 10 Sep 2021 08:41:02 +0200 > wrote: > > > (I'm just asking, because I've seen this complaint a couple > > of times for a well-formed multipart message: personally, I'd > > be OK with it, but I'd like to know how the consensus is). > > I think it has problems. One case is where the author composes in > HTML, and uses colors, emphasis, etc. to make his points, and those > are stripped out of the plain text version, thereby distorting the > author's intent. > > (I also think that if one must use colors, emphasis, etc. as part of > one's writing, then one is not a very good writer. On the other > tentacle, one should not expect good writing from nerds.) > Do it in DTP and attach it, if you must. I decide whether to read it. Sadly, much html comes of of MS software, and takes about ten pages of markup to include three text lines. -- Joe
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, 10 Sep 2021 08:41:02 +0200 wrote: > (I'm just asking, because I've seen this complaint a couple > of times for a well-formed multipart message: personally, I'd > be OK with it, but I'd like to know how the consensus is). I think it has problems. One case is where the author composes in HTML, and uses colors, emphasis, etc. to make his points, and those are stripped out of the plain text version, thereby distorting the author's intent. (I also think that if one must use colors, emphasis, etc. as part of one's writing, then one is not a very good writer. On the other tentacle, one should not expect good writing from nerds.) -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/ pgpeXzpsQRpDP.pgp Description: OpenPGP digital signature
Re: How to improve my question in stackoverflow?
On Fri, Sep 10, 2021 at 08:41:02AM +0200, to...@tuxteam.de wrote: > The original mail was a passable MIME multipart/alternative > with a plain text part. I /think/ that is OK, what do others > think? See below. On Fri, Sep 10, 2021 at 08:25:05AM +0200, to...@tuxteam.de wrote: > On Thu, Sep 09, 2021 at 04:27:01PM -0600, William Torrez Corea wrote: > > *Book.cpp* > > > > #include #include #include #include #include > > #include using namespace std; > > The line above looks very strange. Usually there is one #include > directive per line. Something seems broken with your "book". What's broken, I'm almost certain, is that this mega-line was generated by a malformed HTML to text conversion. In the general case, sure, it's not *terrible* if someone sends multi-part text + HTML messages to the mailing list. But this breaks down in some cases, and causes the text part of the message to be mangled. Sometimes the readers will be able to discern this, and figure out what the text was supposed to look like. Other times, we cannot. So, the *best* thing to do would be to send plain text only. The second best thing is to send mixed text and HTML, and try your hardest to apply whatever heuristics and hacks you can think of to make the text part as readable as possible. The second-worst thing you can do is to send HTML only. The absolute worst thing you can do is send HTML (with or without text) and then act all arrogant and haughty, demanding that the entire mailing list community conform to your personal whims. (William did not do this, as far as I know, but there was a recent poster who did.)
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, 10 Sep 2021 14:50:46 +0530 Pankaj Jangid wrote: > writes: > > > (I'm just asking, because I've seen this complaint a couple > > of times for a well-formed multipart message: personally, I'd > > be OK with it, but I'd like to know how the consensus is). > > I feel that it is okay now to send we formatted multipart messages. As > long as I am getting text parts (well-formatted), I have no problem. > I think that's the problem. I get many commercial emails that contain text but are spread out so I have to scroll several pages to read about ten lines, of which three have useful content. Also, hyperlinks are usually absent, so if I want to see one (I don't use links in emails from strangers) I need to pick through the html to find it. -- Joe
Re: How to improve my question in stackoverflow?
> > > Moreover, the included things are files, and by convention they > have a suffix ".h", for "header". I'd expect the above to look > rather like > > #include > #include > #include > #include > #include > #include > This is true for C, but not for C++. With C++ headers could be files or not, so you shouldn't add ".h". The problem is probably "set" written as "Set": C++ is case sensitive. >
Re: HTML mail [was: How to improve my question in stackoverflow?]
On Fri, Sep 10, 2021 at 08:41:02AM +0200, to...@tuxteam.de wrote: The original mail was a passable MIME multipart/alternative with a plain text part. I /think/ that is OK, what do others think? I think that's perfectly reasonable. There /can/ be good reasons for people to include a HTML part, including for reasons of accessibility. As long as a legible text alternative is supplied, I do not think it's reasonable to object to a HTML alternative. -- Please do not CC me for listmail. Jonathan Dowland ✎j...@debian.org https://jmtd.net
Re: HTML mail [was: How to improve my question in stackoverflow?]
to...@tuxteam.de writes: On Thu, Sep 09, 2021 at 07:45:43PM -0400, Jim Popovitch wrote: [...] > First, most folks on tech mailinglists despise HTML email. The original mail was a passable MIME multipart/alternative with a plain text part. I /think/ that is OK, what do others think? Postel's principle applies, hence: OK :) Perhaps you can teach you mailer to pick the text part for you :-) (I'm just asking, because I've seen this complaint a couple of times for a well-formed multipart message: personally, I'd be OK with it, but I'd like to know how the consensus is). My mail client of choice (cone, not in Debian anymore) seems to prefer displaying the HTML part by default. It does this by converting it to a almost-text-only presentation retaining some things like bold and underline. It gets a little annoying with URLs because it displays link target and label which often leads to the same URL being displayed twice in the terminal. AFAIK I cannot configure it to prefer the text version, but I have not checked that part of the source code to see how difficult it might be to implement such a choice. I can view both variants of the mail content on a case-by-case basis by opening them explicitly. This even works from inside the MUA, nice feature :) . For my usage, it is easiest to have text-only e-mails because those always display nicely by default. Additionally, in this C++ question thread, the source code was given in HTML and text parts of the e-mail and while the `#include` statements were all on separate lines in the HTML, they appear as one long line in the text part. IMHO it causes unnecessary confusion to have two slightly differently displayed parts of the same mail especially for questions with source code :) Btw.: For C++ STL components such as `set` or `string` it is perfectly fine to not append a `.h`. In fact, it would seem not to be standards compliant to append the `.h`, cf. https://stackoverflow.com/questions/15680190 YMMV Linux-Fan öö pgp8MUSLxC_NJ.pgp Description: PGP signature
Re: HTML mail [was: How to improve my question in stackoverflow?]
writes: > (I'm just asking, because I've seen this complaint a couple > of times for a well-formed multipart message: personally, I'd > be OK with it, but I'd like to know how the consensus is). I feel that it is okay now to send we formatted multipart messages. As long as I am getting text parts (well-formatted), I have no problem. -- Regards ~Pankaj
HTML mail [was: How to improve my question in stackoverflow?]
On Thu, Sep 09, 2021 at 07:45:43PM -0400, Jim Popovitch wrote: [...] > First, most folks on tech mailinglists despise HTML email. The original mail was a passable MIME multipart/alternative with a plain text part. I /think/ that is OK, what do others think? Perhaps you can teach you mailer to pick the text part for you :-) (I'm just asking, because I've seen this complaint a couple of times for a well-formed multipart message: personally, I'd be OK with it, but I'd like to know how the consensus is). Cheers - t signature.asc Description: Digital signature
Re: How to improve my question in stackoverflow?
On Thu, Sep 09, 2021 at 04:27:01PM -0600, William Torrez Corea wrote: > Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio > [closed] > > I trying compile an example of a book. William, [DISCLAIMER: I'm not a C++ expert by any measure. I do passably well with C. For example, I don't know whether the C++ #include directive has some extensions wrt the C one. Please, consult a C++ expert] this is not a C++ mailing list. You might be luckier elsewhere. That said... > The program use three classes: Book, Customer and Library. ... your problem doesn't seem to come from "classes" > *Book.cpp* > > #include #include #include #include #include > #include using namespace std; The line above looks very strange. Usually there is one #include directive per line. Something seems broken with your "book". Moreover, the included things are files, and by convention they have a suffix ".h", for "header". I'd expect the above to look rather like #include #include #include #include #include #include (NOTE: they start at the very beginning of the line: indentation here is for readability). Or something similar. Plus, you'd have to adapt your compiler options for it to actually find those files: quoting them between "<...>" will direct it to look into /usr/include. A "/usr/include/string.h" does exist (most of the time ;-), but typically no "/usr/include/set.h", so you'll have to adapt the compiler call (via the -I option). If your book doesn't explain this, it is very broken indeed. I'd look for another book :-) Likewise, I'd expect that last thing: using namespace std; to appear in a line of itself. [...] > g++ -g -Wall Book.cpp book.h -o book > > The result expected is bad. > > Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio Another suggestion: when posting on international mailing lists, set your locale to something with English error messages (for example, do "export LANG=C"). Most people won't be able to understand Spanish error messages. When asking for help, it helps helping others to help you :) > #include > ^ > compilation terminated. What this is telling you is that the compiler has looked into all what it considers to be system directories and hasn't found a file named like this. Probably not surprising. The code you showed looks suspicious anyway, as stated above. > This example was tested from another compiler. The library is not > recognized. > > *The book is C++17 By Example, published by Packt.* If your book doesn't tell you (at least roughly) how to talk to your C++ compiler, I'd suggest looking for another book :) To direct your compiler to look at some other include directories, you use the -I option, as stated above. To see where your compiler is searching for includes, you can do `gcc -xc++ -E -v -' (note: if it is plain C you are interested in, it would be `gcc -xc -E -v -'). Cheers - t signature.asc Description: Digital signature
Re: How to improve my question in stackoverflow?
On Thu, 2021-09-09 at 16:27 -0600, William Torrez Corea wrote: > Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio > [closed] First, most folks on tech mailinglists despise HTML email. Second, let me help you help yourself. Go to https://www.debian.org/distrib/packages and near the bottom of the page you can "Search the contents of packages". Select for "packages that contain files named like this" and enter "set.h". You will see a results page with a list of packages that contain that file. Now, if you tell us which version of Debian you are running than someone here can tell you which version of libstdc++ you will need for set.h. hth, -Jim P.
[OT] C++ Book Question (Was: Re: How to improve my question in stackoverflow?)
William Torrez Corea writes:
Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio
[closed]
I trying compile an example of a book.
The program use three classes: Book, Customer and Library.
The question is offtopic for debian-user, how did it get here?
Also, how are subject and content related?
When giving the source code, give it in entirety, i.e. including the missing
"customer.h", "library.h" and others. Also, for such long source codes,
it seems preferrable to provide them as an attachment rather than inline.
Book.cpp
#include
[...]
When i compile the example with the following command:
g++ -g -Wall Book.cpp book.h -o book
The result expected is bad.
Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio
#include
^
compilation terminated.
[...]
The book is C++17 By Example, published by Packt.
[...]
The immediate problem is with the case "Set" vs. "set". In your source code
above you correctly have `#include `, but the error message suggests
that the `Book.cpp` you are trying to compile still has `#include ` as
displayed by the compiler.
In fact, this seems to be a known erratum for the book sample codes:
https://github.com/PacktPublishing/CPP17-By-Example/issues/1
Clone the repository to get the entire sample source code. I could get to
compile the `Chapter04` example by making changes as attached in
`patchbook.patch`. Apply it with
patch --strip 1 < patchbook.patch
from inside the repository.
HTH
Linux-Fan
öö
diff --git a/Chapter04/LibraryPointer/Book.cpp b/Chapter04/LibraryPointer/Book.cpp
index ae86fd2..62f60f5 100644
--- a/Chapter04/LibraryPointer/Book.cpp
+++ b/Chapter04/LibraryPointer/Book.cpp
@@ -1,9 +1,9 @@
-#include
-#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
using namespace std;
#include "Book.h"
@@ -84,4 +84,4 @@ ostream& operator<<(ostream& outStream, const Book& book) {
}
return outStream;
-}
\ No newline at end of file
+}
diff --git a/Chapter04/LibraryPointer/Customer.cpp b/Chapter04/LibraryPointer/Customer.cpp
index ac17964..31ffe1d 100644
--- a/Chapter04/LibraryPointer/Customer.cpp
+++ b/Chapter04/LibraryPointer/Customer.cpp
@@ -1,8 +1,8 @@
-#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
using namespace std;
#include "Book.h"
@@ -87,4 +87,4 @@ ostream& operator<<(ostream& outStream, const Customer& customer){
}
return outStream;
-}
\ No newline at end of file
+}
diff --git a/Chapter04/LibraryPointer/Library.cpp b/Chapter04/LibraryPointer/Library.cpp
index 10b4ac4..2c6f1a7 100644
--- a/Chapter04/LibraryPointer/Library.cpp
+++ b/Chapter04/LibraryPointer/Library.cpp
@@ -1,10 +1,10 @@
-#include
-#include
-#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
using namespace std;
#include "Book.h"
@@ -611,4 +611,4 @@ Library::~Library() {
for (const Customer* customerPtr : m_customerPtrList) {
delete customerPtr;
}
-}
\ No newline at end of file
+}
diff --git a/Chapter04/LibraryPointer/Main.cpp b/Chapter04/LibraryPointer/Main.cpp
index 18d1637..586b47e 100644
--- a/Chapter04/LibraryPointer/Main.cpp
+++ b/Chapter04/LibraryPointer/Main.cpp
@@ -1,15 +1,16 @@
-#include
-#include
-#include
-#include
-#include
-#include
+#include
+#include
+#include
+#include
+#include
+#include
using namespace std;
#include "Book.h"
#include "Customer.h"
#include "Library.h"
-void main() {
+int main() {
Library();
-}
\ No newline at end of file
+ return 0;
+}
pgpUlyJNnqpAw.pgp
Description: PGP signature
How to improve my question in stackoverflow?
Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio
[closed]
I trying compile an example of a book.
The program use three classes: Book, Customer and Library.
*Book.cpp*
#include #include #include #include #include
#include using namespace std;
#include "book.h"
#include "customer.h"
#include "library.h"
// default constructor
Book::Book(){
// Empty
}
Book::Book(const string& author, const string& title)
:m_author(author),
m_title(title){
// empty
}
// methods
// They only read and write the author and title of the book
void Book::read(ifstream& inStream){
getline(inStream,m_author);
getline(inStream,m_title);
}
void Book::write(ofstream& outStream) const{
outStream << m_author << endl;
outStream << m_title << endl;
}
/* When a customer reserves a book, the pointer to the customer
* Object is added to the reservation pointer list of the book */
int Book::reserveBook(Customer* borrowerPtr){
m_reservationPtrList.push_back(borrowerPtr);
return m_reservationPtrList.size();
}
/* When a customer returns a book, we simply set m_borrowerPtr to nullptr*/
void Book::returnBook(){
m_borrowerPtr = nullptr;
}
/* the removeReservation method simply removes the customer
* pointer from the reservation list*/
void Book::removeReservation(Customer* customerPtr){
m_reservationPtrList.remove(customerPtr);
}
/* the output stream operator writes the title and author, the
customer that has borrowed the book, and the customers that have
reserved the book */
ostream& operator << (ostream& outStream, const Book& book){
outStream << """ << book.m_title << "" by " << book.m_author;
if(book.m_borrowed){
outStream << endl << " Borrowed by: "
<< Library::s_customerMap[book.m_customerId].name()
<< ".";
}
if(!book.m_reservationList.empty()){
outStream << endl << " Reserved by: ";
bool first = true;
for(int customerId : book.m_reservationList){
outStream << (first ? "" : ",")
<< Library::s_customerMap[customerId].name();
first = false;
}
outStream << ".";
}
return outStream;
}
*book.h*
class Customer;
class Book {
public:
Book();
Book(const string& author,const string& title);
const string& author() const{return m_author;}
const string& title() const{return m_title;}
void read(ifstream& inStream);
void write(ofstream& outStream) const;
int reserveBook(Customer* customerPtr);
void removeReservation(Customer* customerPtr);
void returnBook();
/*borrowedPtr method returns the address of the customer who
has borrowed the book*/
Customer*& borrowerPtr() {return m_borrowerPtr;}
const Customer* borrowerPtr() const {return m_borrowerPtr;}
/* reservationPtrList returns a list of customer pointers
instead of integer values*/
list& reservationPtrList(){
return m_reservationPtrList;
}
const list reservationPtrList() const{
return m_reservationPtrList;
}
friend ostream& operator<<(ostream& outStream, const Book& book);
private:
string m_author, m_title;
Customer* m_borrowerPtr = nullptr;
/* holds a list of pointers to the customers that have
reserved the book*/
list m_reservationPtrList;
}
When i compile the example with the following command:
g++ -g -Wall Book.cpp book.h -o book
The result expected is bad.
Book.cpp:1:10: fatal error: Set: No existe el fichero o el directorio
#include
^
compilation terminated.
This example was tested from another compiler. The library is not
recognized.
*The book is C++17 By Example, published by Packt.*
--
With kindest regards, William.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄
