New text quote protocol?
Daniel J. Stern
The long string of > characters can really make a hash of things in an
extended mail or news thread. I've been experimenting with numeric
substitution for all but one such character, replacing this:
>>> > > How do you adjust the valves on a '62 Valiant?
>>> > That depends, do you want them adjusted fast or properly?
>>> > The procedure in the FSM is dumb, it has you marking out angles and
>>> > all kinds of dumb stuff on the vibration damper.
>>> Me, I adjust them with the engine hot and running.
>> Good theory, but what about cylinder 6, unreachable under the heater
>> housing if you've got the 225?
> I've got the 170, so it's not as much of a problem...how I deal with
> cylinder 6 on a 225 depends on how ambitious I'm feeling.
with this:
5> How do you adjust the valves on a '62 Valiant?
4> That depends, do you want them adjusted fast or properly?
4> The procedure in the FSM is dumb, it has you marking out angles and
4> all kinds of dumb stuff on the vibration damper.
3> Me, I adjust them with the engine hot and running.
2> Good theory, but what about cylinder 6, unreachable under the heater
2> housing if you've got the 225?
> I've got the 170, so it's not as much of a problem...how I deal with
> cylinder 6 on a 225 depends on how ambitious I'm feeling.
I've gotten a lot of positive response on this method, which simply
amounts to counting the total number of quote indicators, deleting all but
one of them, and putting that number before the single indicator. But
doing it manually is pretty tedious. Would it be tough to smarten-up PINE
to do this automatically, d'you think?
DS
Will Yardley
<Pine.SOL.4.44.030409...@alumni.engin.umich.edu>,
Daniel J. Stern wrote:
> The long string of > characters can really make a hash of things in an
> extended mail or news thread. I've been experimenting with numeric
> substitution for all but one such character, replacing this:
[snipped]
> 5> How do you adjust the valves on a '62 Valiant?
>
> 4> That depends, do you want them adjusted fast or properly?
> 4> The procedure in the FSM is dumb, it has you marking out angles and
> 4> all kinds of dumb stuff on the vibration damper.
[...etc]
> I've gotten a lot of positive response on this method, which simply
> amounts to counting the total number of quote indicators, deleting all
> but one of them, and putting that number before the single indicator.
> But doing it manually is pretty tedious. Would it be tough to
> smarten-up PINE to do this automatically, d'you think?
Personally, I don't like this way of quoting, because it's non-standard
and apt to cause more confusion / messiness than it fixes,
I think the best way to implement this, though, would be to use an
alternate editor; vim or emacs should be able to do this for you fairly
easily.
--
No copies, please.
To reply privately, simply reply; don't remove anything.
Eduardo Chappa
:) The long string of > characters can really make a hash of things in an
:) extended mail or news thread. I've been experimenting with numeric
:) substitution for all but one such character, replacing this:
:)
:) >>> > > How do you adjust the valves on a '62 Valiant?
:)
:) >>> > That depends, do you want them adjusted fast or properly? The
:) >>> > procedure in the FSM is dumb, it has you marking out angles and
:) >>> > all kinds of dumb stuff on the vibration damper.
:)
:) >>> Me, I adjust them with the engine hot and running.
:)
:) >> Good theory, but what about cylinder 6, unreachable under the heater
:) >> housing if you've got the 225?
:)
:) > I've got the 170, so it's not as much of a problem...how I deal with
:) > cylinder 6 on a 225 depends on how ambitious I'm feeling.
:)
:) with this:
:)
:) 5> How do you adjust the valves on a '62 Valiant?
:)
:) 4> That depends, do you want them adjusted fast or properly?
:) 4> The procedure in the FSM is dumb, it has you marking out angles and
:) 4> all kinds of dumb stuff on the vibration damper.
:)
:) 3> Me, I adjust them with the engine hot and running.
:)
:) 2> Good theory, but what about cylinder 6, unreachable under the heater
:) 2> housing if you've got the 225?
:)
:) > I've got the 170, so it's not as much of a problem...how I deal with
:) > cylinder 6 on a 225 depends on how ambitious I'm feeling.
:)
:) I've gotten a lot of positive response on this method, which simply
:) amounts to counting the total number of quote indicators, deleting all
:) but one of them, and putting that number before the single indicator.
:) But doing it manually is pretty tedious. Would it be tough to
:) smarten-up PINE to do this automatically, d'you think?
I think this is an interesting idea, if a lot of people agree on it and
use this convention should be enough reason to justify its existence. As
you can see I use a completely non-standar quote string, and part of your
problem will be to determine what to do in these cases. You can not just
ignore this, since it happens in real life and can not say that I
shouldn't do that because I do it anyway (and I'm not the only one, so
even if you could convince me not to do it, you would have much more
people to convince not to do this). The bottom line: decide what to do
when there are no standard ">".
It's interesting to see that your method would imply that "> 4>" is
equivalent to '5>" and that looks like something hard to implement, but if
you are for it, go for it.
I prefer other methods to deal with the same problem by fitting the quoted
text to the specified length of the line. That's another approach, which
makes the text quite readable too (I think).
Anyway, you will find some oposition in many people. If you can create a
good system to make this work and convince a good number of people to use
it let me know.
Daniel J. Stern
> :) I've gotten a lot of positive response on this method, which simply
> :) amounts to counting the total number of quote indicators, deleting all
> :) but one of them, and putting that number before the single indicator.
> I think this is an interesting idea, if a lot of people agree on it and
> use this convention should be enough reason to justify its existence.
This, of course, is the catch-22 of development. Nobody wants to develop
for nonstandard practices because not many people use 'em, but not many
people use nonstandard practices because there's no "infrastructure" for
it.
> you can see I use a completely non-standar quote string, and part of your
> problem will be to determine what to do in these cases.
Yep, thought of that. Don't know how to get around it because I am not a
programmer.
> You can not just ignore this, since it happens in real life
Right. My thinking: it would almost certainly take some *very* fancy
footwork to catch a hundred percent of the nonstandard quote markers, but
it would be rather easy to catch, say, 90 percent of them. I'd guess 85%
or better do use the > character, and an additional 5 percent probably use
only about five different alternatives.
> It's interesting to see that your method would imply that "> 4>" is
> equivalent to '5>"
Yes. The trick would be to preclude the appearance of > 4> by causing PICO
(or whatever) to count the existing >s, total them, and output the count
to the left of a single >, *EVERY* time. So if I were responding to a
message that included the string:
4> I think PINE is keen
my response would include the string:
5> I think PINE is keen
> if you are for it, go for it.
I'd love to. I flunked the only programming class I ever took (I got an
F-minus-minus in C++, and only later found out that it was the wrong idea
to take C++ as an intro to programming). Therefore, I totally lack the
means.
> Anyway, you will find some oposition in many people.
Indeed. So always with creation and modifications of standards and
protocols!
DS
Aaron S. Hawley
I'd be interested to know what standards exist for "quoting" even if these
standars are unwritten, but recognized by mailers and news readers for
whatever reason.. if the standard is "netiquette", then fuck it.
cause my guess is greater-than-symbols for quoting have about the same
weight as ascii art web pages, nothing!
this numeric approach seems like a better approach. and i've seen people
switching to tabs or other non-standard methods of whitespace indentation.
what's has the effect of this been?
i think the most important question is what is most accessible for blind
folks. is the current system of greater-than-symbols adequate for people
with screenreaders?
/a
Daniel J Stern
> not so sure this thread is actually related to Pine still, but..
You're probably right. Suggestions on more appropriate groups?
> this numeric approach seems like a better approach.
> i think the most important question is what is most accessible for blind
> folks. is the current system of greater-than-symbols adequate for people
> with screenreaders?
I have heard some screenreaders *really* choke on 'em, reading out
"Greater than. Greater than. Bar. Greater than. Greater than."
I hadn't really thought of screenreaders, but I imagine they could with
relative ease be programmed to read the string:
5> Does anyone have a good recipe for turkey pot pie?
4> I like the recipe at www.cooksillustrated.com, but I usually add more
4> pot than they call for!
3> Heh. Don't let John Ashcroft catch you making that kind of pot pie!
2> Yeah, he'll decide you're a terrorist.
> Eek! Terrorists!
as "Five quote. Does anyone have a good recipe for turkey pot pie? Four
quote. I like the recipe at www.cooksillustrated.com, but I usually add
more pot than they call for. Three quote. Heh. Don't let John Ashcroft
catch you making that kind of pot pie! Two quote. Yeah, he'll decide
you're a terrorist. Quote. Eek! Terrorists!".
DS
Eduardo Chappa
:) On Wed, 9 Apr 2003, Eduardo Chappa wrote:
:)
:) > :) I've gotten a lot of positive response on this method, which
:) > :) simply amounts to counting the total number of quote indicators,
:) > :) deleting all but one of them, and putting that number before the
:) > :) single indicator.
:)
:) > I think this is an interesting idea, if a lot of people agree on it
:) > and use this convention should be enough reason to justify its
:) > existence.
:)
:) This, of course, is the catch-22 of development. Nobody wants to
:) develop for nonstandard practices because not many people use 'em, but
:) not many people use nonstandard practices because there's no
:) "infrastructure" for it.
You would be surprised to see how many people care about support for this.
I maintain a patch that gives support in Pico (and therefore Pine) so that
people can justify strange combinations of quote strings. It's one of my
most popular patches. So I am inclined to believe that not only people
want to have their editors recognize this kind of behavior, but also
support it to the extent it can be supported, so i disagree with you on
this. Of course there are some other people that believe that ">" is the
only one quote string that should ever exist, but that's not what I am
talking about here.
:) > you can see I use a completely non-standar quote string, and part of
:) > your problem will be to determine what to do in these cases.
:)
:) Yep, thought of that. Don't know how to get around it because I am not
:) a programmer.
You have to realize that this does not requier you to be a programer. Why?
because you have to create the model, not implement it. You will probably
have to consult with many people in order to figure out what is the best
decision to make for every complicated situation.
:) > You can not just ignore this, since it happens in real life
:)
:) Right. My thinking: it would almost certainly take some *very* fancy
:) footwork to catch a hundred percent of the nonstandard quote markers,
:) but it would be rather easy to catch, say, 90 percent of them. I'd
:) guess 85% or better do use the > character, and an additional 5 percent
:) probably use only about five different alternatives.
It's impossible to catch 100% of them, agree. But just to give you an
example of something very related to this is the algorithm for threading
in Pine. The algorithm does not catch 100% of the thread structures, yet
people use it, nobody complains much about the things it does not catch
(anf even if you do it won't change). I am not saying this to complain
about threading, or its pitfalls, I am saying this to show you that even
in a case where there is more information available to you to determine
the thread structure (than what you would have to determine the quote
string), it is not done with 100% of accuracy, yet it works in most cases,
so I'd say just try to maximize how much you can recognize. In a perfect
world the problem of justification of several quote strings is equivalent
to the problem of threading.
:) > It's interesting to see that your method would imply that "> 4>" is
:) > equivalent to '5>"
:)
:) Yes. The trick would be to preclude the appearance of > 4> by causing
:) PICO (or whatever) to count the existing >s, total them, and output the
:) count to the left of a single >, *EVERY* time. So if I were responding
:) to a message that included the string:
:)
:) 4> I think PINE is keen
:)
:) my response would include the string:
:)
:) 5> I think PINE is keen
Ouch, this is asking for something that is not going to happen, anywhere.
Changing this in Pine/Pico is a huge change. If I was you, I would just
ask for ">>>" to be changed to "3>" when justified and "> 2>" to be
changed to "3>" if appropriate. That will get you farther to where you
want to get
:) > if you are for it, go for it.
:)
:) I'd love to. I flunked the only programming class I ever took (I got an
:) F-minus-minus in C++, and only later found out that it was the wrong
:) idea to take C++ as an intro to programming). Therefore, I totally lack
:) the means.
Don't worry this does not have to do with knowing C++, it has to do with
convincing those who know it.
Gopi Sundaram
> Suggestions on more appropriate groups?
comp.mail.misc
>> this numeric approach seems like a better approach.
Yuck. I personally prefer "> " followed by ">> " and so on. I like it
because there are strong visual cues to the depth of quoting.
>> i think the most important question is what is most accessible for
>> blind folks.
Here's where the visual cues break down. But taking Daniel's idea, it
can be implemented in screen readers. So if it encounters ">>>> " it
reads "quote 4" and ">> " as "quote 2", and so on.
This way, most people's email software doesn't have to be changed, the
vast body of current messages doesn't have to be changed, and we fix
poor software support for existing messages.
Since Eduardo already has an algorithm for recognizing mixed quote-
prefixes, retro-fitting it to other software shouldn't be too difficult.
Does anyone know an open-source screen reader that needs programmers?
--
Gopi Sundaram
http://www.zrox.net/Mail/Pine/
Aaron S. Hawley
> Does anyone know an open-source screen reader that needs programmers?
you might want to speak with the folks at the Blind Linux project