string> missing?

string> missing?

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

Hi guys,

I just saw that we do have `string<' (`string-lessp') but we miss
`string>'?  Is this on purpose?

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: string> missing?

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Date: Wed, 03 Jun 2015 11:05:11 +0200
> 
> I just saw that we do have `string<' (`string-lessp') but we miss
> `string>'?  Is this on purpose?

What would '(string> A B)' do that '(string< B A)' doesn't?

Re: string> missing?

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 472 bytes --]


Eli Zaretskii writes:

>> From: Nicolas Petton <nicolas@petton.fr>
>> Date: Wed, 03 Jun 2015 11:05:11 +0200
>> 
>> I just saw that we do have `string<' (`string-lessp') but we miss
>> `string>'?  Is this on purpose?
>
> What would '(string> A B)' do that '(string< B A)' doesn't?

Right, but then why do we have `(> a b)'?  For the sake completeness, as
we have #'> and #'<, I'd add `string>' to Elisp.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: string> missing?

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

Nicolas Petton <nicolas@petton.fr> writes:

>>> From: Nicolas Petton <nicolas@petton.fr> Date: Wed, 03 Jun 2015
>>> 11:05:11 +0200
>>> 
>>> I just saw that we do have `string<' (`string-lessp') but we miss
>>> `string>'?  Is this on purpose?
>>
>> What would '(string> A B)' do that '(string< B A)' doesn't?
>
> Right, but then why do we have `(> a b)'?  For the sake completeness, as
> we have #'> and #'<, I'd add `string>' to Elisp.

With that argument, we'd also need string<= and string>=.  But I'd agree
that

  (sort #'string> list)

is a bit nicer than

  (sort (lambda (a b) (string< b a)) list)

Bye,
Tassilo

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 212 bytes --]

Re: string> missing?

[Nick Andryshak]

> What would '(string> A B)' do that '(string< B A)' doesn't?

Functionally, nothing, but it seems silly to have only one without the
other, don't you think? Why would a language have '<' without '>'?

> With that argument, we'd also need string<= and string>=.

Nothing wrong with that.

- Nick

Re: string> missing?

[Eli Zaretskii]

> From: Nick Andryshak <nandryshak@gmail.com>
> Cc: Nicolas Petton <nicolas@petton.fr>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Wed, 03 Jun 2015 11:46:44 -0400
> 
> > What would '(string> A B)' do that '(string< B A)' doesn't?
> 
> Functionally, nothing, but it seems silly to have only one without the
> other, don't you think?

No, I don't.

> Why would a language have '<' without '>'?

Because it's enough?

> > With that argument, we'd also need string<= and string>=.
> 
> Nothing wrong with that.

That's just the tip of the iceberg.  We have quite a few of other
similar situations in Emacs Lisp.

Re: string> missing?

[Nick Andryshak]

Eli Zaretskii writes:

>> Why would a language have '<' without '>'?
>
> Because it's enough?

Should 'enough' be considered an acceptable standard?

Quote, atom, eq, cons, car, cdr, and cond are 'enough', right? Should
Emacs be reduced to this handful of functions?

>> > With that argument, we'd also need string<= and string>=.
>> 
>> Nothing wrong with that.
>
> That's just the tip of the iceberg.  We have quite a few of other
> similar situations in Emacs Lisp.

I don't think adding in a few small functions to satisfy some
inconsistencies makes the rest of that iceberg very menacing. I
understand where you're coming from with this argument, but I don't
really buy it. Emacs has matching functions for < and <=, why not
string<?

- Nick

Re: string> missing?

[Eli Zaretskii]

> From: Nick Andryshak <nandryshak@gmail.com>
> Cc: tsdh@gnu.org, nicolas@petton.fr, emacs-devel@gnu.org
> Date: Wed, 03 Jun 2015 12:10:50 -0400
> 
> >> Why would a language have '<' without '>'?
> >
> > Because it's enough?
> 
> Should 'enough' be considered an acceptable standard?

Yes.

> Quote, atom, eq, cons, car, cdr, and cond are 'enough', right?

No.

> > That's just the tip of the iceberg.  We have quite a few of other
> > similar situations in Emacs Lisp.
> 
> I don't think adding in a few small functions to satisfy some
> inconsistencies makes the rest of that iceberg very menacing.

I see no reason to be "consistent" here.  There's no requirement to
have in Emacs all possible inequality functions, just for consistency.

Now, if there are good reasons to add specifically this function,
let's hear them.  "Consistency" isn't such a reason, because then we'd
need to add gobs of other functions for similar "consistency" reasons.

> I understand where you're coming from with this argument, but I
> don't really buy it.

Then don't.  It's OK to disagree about something, nothing wrong about
that.  Fortunately, you can have this function for you, if you need
it, with a simple one-liner.

Re: string> missing?

[Nick Andryshak]

>> > That's just the tip of the iceberg.  We have quite a few of other
>> > similar situations in Emacs Lisp.
>> 
>> I don't think adding in a few small functions to satisfy some
>> inconsistencies makes the rest of that iceberg very menacing.
>
> I see no reason to be "consistent" here.  There's no requirement to
> have in Emacs all possible inequality functions, just for consistency.
>
> Now, if there are good reasons to add specifically this function,
> let's hear them.  "Consistency" isn't such a reason, because then we'd
> need to add gobs of other functions for similar "consistency" reasons.

What good reasons are there specifically to keep the '>' function? What
does '(> A B)' do that '(< B A)' doesn't?

- Nick

Re: string> missing?

[Andreas Schwab]

Nick Andryshak <nandryshak@gmail.com> writes:

> What good reasons are there specifically to keep the '>' function?

History.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: string> missing?

[Alan Mackenzie]

On Wed, Jun 03, 2015 at 12:50:47PM -0400, Nick Andryshak wrote:
> >> > That's just the tip of the iceberg.  We have quite a few of other
> >> > similar situations in Emacs Lisp.

> >> I don't think adding in a few small functions to satisfy some
> >> inconsistencies makes the rest of that iceberg very menacing.

> > I see no reason to be "consistent" here.  There's no requirement to
> > have in Emacs all possible inequality functions, just for consistency.

> > Now, if there are good reasons to add specifically this function,
> > let's hear them.  "Consistency" isn't such a reason, because then we'd
> > need to add gobs of other functions for similar "consistency" reasons.

> What good reasons are there specifically to keep the '>' function? What
> does '(> A B)' do that '(< B A)' doesn't?

For convenience.  `>' is used a LOT.  It would be a positive pain to be
without it.

On the other hand, `string>' would be used very seldomly.  So seldomly,
that it probably wouldn't be worth the space it would fill up.  But if
anybody disagrees, he is able to add `string>' to his .emacs, or his own
packages.

> - Nick

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: string> missing?

[Eli Zaretskii]

> From: Nick Andryshak <nandryshak@gmail.com>
> Cc: tsdh@gnu.org, nicolas@petton.fr, emacs-devel@gnu.org
> Date: Wed, 03 Jun 2015 12:50:47 -0400
> 
> What good reasons are there specifically to keep the '>' function? What
> does '(> A B)' do that '(< B A)' doesn't?

If you want to argue for removal of one of them, feel free.

But that doesn't reflect in any way on the issue at hand.  Once again,
there's no requirement to be "consistent" in this sense.

Re: string> missing?

[Nick Andryshak]

>> What good reasons are there specifically to keep the '>' function?
>> What does '(> A B)' do that '(< B A)' doesn't?
>
> If you want to argue for removal of one of them, feel free.

Perhaps my comparison was not explicit enough: it was intended to make
you think about why both < and > exist when one is clearly "enough", and
then apply those same reasons to the issue at hand.

So, why do both exist?

Readability, maybe. Sometimes it's nicer or it makes more sense to use
"greater than" over "less than" or vice versa.

> But that doesn't reflect in any way on the issue at hand. Once again,
> there's no requirement to be "consistent" in this sense.

Of course consistency is not a /requirement/, I never claimed it was.
But I think we would agree that it's usually a good goal to strive
towards because inconsistent leads to confusing and a bad user
experience.

Having one comparison operator without the other is simply confusing to
developers. If I'm writing code where '<' exists and works, I believe
it's reasonable for me to assume that '>' will also. Apply this same
logic to string< and string>.

- Nick

Re: string> missing?

[Eli Zaretskii]

> From: Nick Andryshak <nandryshak@gmail.com>
> Cc: tsdh@gnu.org, nicolas@petton.fr, emacs-devel@gnu.org
> Date: Wed, 03 Jun 2015 15:34:14 -0400
> 
> >> What good reasons are there specifically to keep the '>' function?
> >> What does '(> A B)' do that '(< B A)' doesn't?
> >
> > If you want to argue for removal of one of them, feel free.
> 
> Perhaps my comparison was not explicit enough: it was intended to make
> you think about why both < and > exist when one is clearly "enough", and
> then apply those same reasons to the issue at hand.
> 
> So, why do both exist?

Because they do.  The cause is lost in history.

> Of course consistency is not a /requirement/, I never claimed it was.
> But I think we would agree that it's usually a good goal to strive
> towards because inconsistent leads to confusing and a bad user
> experience.

No, I don't agree.

> Having one comparison operator without the other is simply confusing to
> developers. If I'm writing code where '<' exists and works, I believe
> it's reasonable for me to assume that '>' will also. Apply this same
> logic to string< and string>.

That's exactly the point: there's no need to apply the same logic to
both cases.

And don't forget that you also have compare-strings, which can do
both.

Re: string> missing?

[Nick Andryshak]

> Because they do.  The cause is lost in history.

> No, I don't agree.

> That's exactly the point: there's no need to apply the same logic to
> both cases.

Those are entirely unreasonable answers.

- Nick

Re: string> missing?

[Jay Belanger]

Nick Andryshak <nandryshak@gmail.com> writes:

>> Because they do.  The cause is lost in history.
>
>> No, I don't agree.
>
>> That's exactly the point: there's no need to apply the same logic to
>> both cases.
>
> Those are entirely unreasonable answers.

In what way is any one of the answers the least bit unreasonable?

Re: string> missing?

[Nick Andryshak]

Jay Belanger writes:

> In what way is any one of the answers the least bit unreasonable?

Since you asked:

> Because they do.

"Because they do" is a non-answer.

> The cause is lost in history.

Nonsense.

> No, I don't agree.

I really don't understand why Eli would say something like this. I think
it contradicts his work.

> That's exactly the point: there's no need to apply the same logic to
> both cases.

This makes no sense: I'm sure many people have seen the function
'string<' and assumed that there exists a counterpart 'string>'. I think
that this is a reasonable assumption to make. In fact, that's probably
why we're having this (rather silly) discussion in the first place.

- Nick

Re: string> missing?

[Jay Belanger]

>> In what way is any one of the answers the least bit unreasonable?
>
> Since you asked:
>
>> Because they do.
>
> "Because they do" is a non-answer.

The complete answer he gave was:
  "Because they do.  The cause is lost in history."
In other words: "We don't know", which is a perfectly good answer.

>> The cause is lost in history.
>
> Nonsense.

??????

>> No, I don't agree.
>
> I really don't understand why Eli would say something like this.

So disagreeing with you is unreasonable?

> I think it contradicts his work.

?????

>> That's exactly the point: there's no need to apply the same logic to
>> both cases.
>
> This makes no sense:

It does to me.
You not understanding something isn't the same as it not making sense.

Eli gave perfectly reasonable answers, you just didn't like them.

Re: string> missing?

[Thibaut Verron]

Nick Andryshak <nandryshak <at> gmail.com> writes:


> Having one comparison operator without the other is simply confusing to
> developers. If I'm writing code where '<' exists and works, I believe
> it's reasonable for me to assume that '>' will also. Apply this same
> logic to string< and string>.
> 

I did run into a similar issue not long ago, when I had to test for emacs 
version in my .emacs. It took me a few minutes to find out that no, 
version> doesn't exist. It left me with a bitter taste of waste, like some 
simplicity that was given up for no apparent reason. 

But I could see a possible reason for this missing function: version> and 
version< are not as symmetrical as they would seem, and writing code "for 
all emacs versions more recent than this one" is almost certainly going to 
break something in the future.

What is understandable for version> seems to be nonsense for string> 
though. In this case, the functions are symmetrical, why have one and not 
the other?

And about the additional string<= and string>=, I'd say these are even 
more useful, because testing strings for equality in emacs lisp is already 
tricky enough! And, it is possible to test if a string is less than or 
equal to another faster than the combination of both tests.

Thibaut

Re: string> missing?

[Stefan Monnier]

> testing strings for equality in emacs lisp is already tricky enough!

Now, regardless of whether I agree with the rest of what is being said
in this thread, this part really puzzles me.  I do think there are some
tricky/subtle issues in string equality testing in Emacs, but these are
sufficiently subtle that most people will never know about them.

So, what are you referring to here?


        Stefan

Re: string> missing?

[Thibaut Verron]

2015-06-04 0:25 GMT+02:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>
> > testing strings for equality in emacs lisp is already tricky enough!
>
> Now, regardless of whether I agree with the rest of what is being said
> in this thread, this part really puzzles me.  I do think there are some
> tricky/subtle issues in string equality testing in Emacs, but these are
> sufficiently subtle that most people will never know about them.
>
> So, what are you referring to here?
>

Mostly to this:

(setq str1 "foo")
(setq str2 "foo")
(setq str3 str1)
(= str1 str2)       ;;==> *error*
(eq str1 str2)      ;;==> nil
(eq str1 "foo")     ;;==> nil
(eq str1 str3)      ;;==> nil
(string= str1 str2) ;;==> t

The first two candidates for a newcomer to string testing don't return
the expected result, because = is really number=, and eq does not test
for structural equality (and is basically useless for strings, as I
understand it). Now maybe tricky is a strong word, after all it is
properly documented once you notice the issue. And I wouldn't be able
to suggest a better way of exposing these functions.

For the thread at hand, obviously if one is looking for a string>
function, one knows about string=. But I can't help but imagine a
developer running into both annoyances on the same day: the first one
has deep roots, but the second one is trivial to fix, couldn't we
spare him that?

Thibaut

Re: string> missing?

[Nicolas Richard]

Thibaut Verron <thibaut.verron@gmail.com> writes:
> Mostly to this:
>
> (setq str1 "foo")
> (setq str2 "foo")
> (setq str3 str1)
> (= str1 str2)       ;;==> *error*
> (eq str1 str2)      ;;==> nil
> (eq str1 "foo")     ;;==> nil
> (eq str1 str3)      ;;==> nil

If that is not a typo, then it is a bug. I get t.

> (string= str1 str2) ;;==> t

And also:
(equal str1 str2) ;;==> t

-- 
Nico

Re: string> missing?

[Thibaut Verron]

2015-06-04 9:44 GMT+02:00 Nicolas Richard <youngfrog@members.fsf.org>:
>
> Thibaut Verron <thibaut.verron@gmail.com> writes:
> > Mostly to this:
> >
> > (setq str1 "foo")
> > (setq str2 "foo")
> > (setq str3 str1)
> > (= str1 str2)       ;;==> *error*
> > (eq str1 str2)      ;;==> nil
> > (eq str1 "foo")     ;;==> nil
> > (eq str1 str3)      ;;==> nil
>
> If that is not a typo, then it is a bug. I get t.


I am 99% sure that it wasn't a typo, but indeed I get t now. I was at
home on windows the first time, and now at work on linux, so I'll need
to retry it tonight to be sure.

>
>
> > (string= str1 str2) ;;==> t
>
> And also:
> (equal str1 str2) ;;==> t

Oh, I didn't know this one. And then it opens up a whole new world of
equality functions, equalp for case-insensitive comparison,
equal-including-properties...

But indeed, it looks like equal is a good candidate for type-agnostic,
dwim-style equality testing.

Thibaut

Re: string> missing?

[Stefan Monnier]

> (setq str1 "foo")
> (setq str2 "foo")
> (setq str3 str1)
> (= str1 str2)       ;;==> *error*
> (eq str1 str2)      ;;==> nil
> (eq str1 "foo")     ;;==> nil
> (eq str1 str3)      ;;==> nil
> (string= str1 str2) ;;==> t

The "standard" equality testing in Elisp is `equal'.
E.g. it's what is used by `add-to-list', `member', and `assoc'.
IOW, usually you're expected to use `equal' unless you need something else.


        Stefan

Re: string> missing?

[Stefan Monnier]

> Apply this same logic to string< and string>.

Emacs is inconsistent.  That's part of its inheritance.
If someone wants to add string>, I'm perfectly OK with it.
But I'm surprised noone is arguing here in favor of dropping string< and
making < and > accept strings instead!


        Stefan

Re: string> missing?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 03 Jun 2015 18:28:13 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, tsdh@gnu.org, nicolas@petton.fr,
> 	emacs-devel@gnu.org
> 
> > Apply this same logic to string< and string>.
> 
> Emacs is inconsistent.  That's part of its inheritance.
> If someone wants to add string>, I'm perfectly OK with it.

Why not _remove_ string< and use compare-strings for both jobs?

Re: string> missing?

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Emacs is inconsistent.  That's part of its inheritance.
>> If someone wants to add string>, I'm perfectly OK with it.
>
> Why not _remove_ string< and use compare-strings for both jobs?

Oh yes, please.  Everybody wants to use a function of 6-7 arguments! ;-)

Fun aside: aside from the reason of symmertry/consistency, I can see at
least two practical advantages of having `string>'.  Whenever it should
be used as predicate of a higher-order function,

  (sort coll #'string>)

is more concise than

  (sort coll (lambda (a b) (string< b a)))

and it is also better to edebug because you are usually not
interested in edebugging the lambda.  (What can possibly go wrong
there?!?)

However, this is true for any other simple predicate aside from number
or string comparison.  So I'd suggest to have a `complement' function
which simply returns a function negating the value of some predicate,
e.g.,

(defun complement (fn)
  "Returns a function calling FN and returning FN's negated value."
  (lambda (&rest args)
    (not (apply fn args))))

Then you can do

  (sort coll (complement #'string<))

which looks like a good compromise wrt conciseness and edebuggability.
Of course, (complement #'string<) is string>= which will work fine for
`sort' but probably not for other higer-order functions.

Grepping the emacs source code, there are indeed at least three
occurrences of (nreverse (sort coll predicate)) which could make use of
that.  And I can also find occurrences of (lambda (a b) (string< b a)).
However, when the number of definitions is what makes a function which
is currently not provided by Elisp important, than it looks to me that
there should be a function for

  (lambda (a b) (string< (car a) (car b)))

For that, `rgrep' delivers 40 matches in the elisp repositories I have
on my disk, and I only searched for

  "(lambda (. .) (string< (car .) (car .)))"

so it has to occur on one line with the exact spacing and 1-char wide
arguments.  So that suggests we want to have a
`car-string-less-than-car' (or indeed want to have the numerical
comparison functions work for strings, too, as Stefan suggested because
there's already `car-less-than-car').

Bye,
Tassilo

Re: string> missing?

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

Way too much bikeshedding for something super trivial. Let's add the
function(s) and be done with it.

On 4 June 2015 at 08:43, Tassilo Horn <tsdh@gnu.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Emacs is inconsistent.  That's part of its inheritance.
> >> If someone wants to add string>, I'm perfectly OK with it.
> >
> > Why not _remove_ string< and use compare-strings for both jobs?
>
> Oh yes, please.  Everybody wants to use a function of 6-7 arguments! ;-)
>
> Fun aside: aside from the reason of symmertry/consistency, I can see at
> least two practical advantages of having `string>'.  Whenever it should
> be used as predicate of a higher-order function,
>
>   (sort coll #'string>)
>
> is more concise than
>
>   (sort coll (lambda (a b) (string< b a)))
>
> and it is also better to edebug because you are usually not
> interested in edebugging the lambda.  (What can possibly go wrong
> there?!?)
>
> However, this is true for any other simple predicate aside from number
> or string comparison.  So I'd suggest to have a `complement' function
> which simply returns a function negating the value of some predicate,
> e.g.,
>
> (defun complement (fn)
>   "Returns a function calling FN and returning FN's negated value."
>   (lambda (&rest args)
>     (not (apply fn args))))
>
> Then you can do
>
>   (sort coll (complement #'string<))
>
> which looks like a good compromise wrt conciseness and edebuggability.
> Of course, (complement #'string<) is string>= which will work fine for
> `sort' but probably not for other higer-order functions.
>
> Grepping the emacs source code, there are indeed at least three
> occurrences of (nreverse (sort coll predicate)) which could make use of
> that.  And I can also find occurrences of (lambda (a b) (string< b a)).
> However, when the number of definitions is what makes a function which
> is currently not provided by Elisp important, than it looks to me that
> there should be a function for
>
>   (lambda (a b) (string< (car a) (car b)))
>
> For that, `rgrep' delivers 40 matches in the elisp repositories I have
> on my disk, and I only searched for
>
>   "(lambda (. .) (string< (car .) (car .)))"
>
> so it has to occur on one line with the exact spacing and 1-char wide
> arguments.  So that suggests we want to have a
> `car-string-less-than-car' (or indeed want to have the numerical
> comparison functions work for strings, too, as Stefan suggested because
> there's already `car-less-than-car').
>
> Bye,
> Tassilo
>
>

[-- Attachment #2: Type: text/html, Size: 3211 bytes --]

Gnus & Mail-Followup-To (was: string> missing?)

[Nicolas Richard]

Tassilo Horn <tsdh@gnu.org> writes:
> there's already `car-less-than-car').

TIL.

I saw that you have set :
Mail-Followup-To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
	<monnier@iro.umontreal.ca>, nandryshak@gmail.com, nicolas@petton.fr,
	emacs-devel@gnu.org

FWIW, it made Gnus set Eli as recipient of my answer. Is it the intended
behaviour ?

-- 
Nico.

Re: Gnus & Mail-Followup-To

[Tassilo Horn]

Nicolas Richard <youngfrog@members.fsf.org> writes:

> Tassilo Horn <tsdh@gnu.org> writes:
>> there's already `car-less-than-car').
>
> TIL.
>
> I saw that you have set :
> Mail-Followup-To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
> 	<monnier@iro.umontreal.ca>, nandryshak@gmail.com, nicolas@petton.fr,
> 	emacs-devel@gnu.org
>
> FWIW, it made Gnus set Eli as recipient of my answer. Is it the intended
> behaviour ?

I don't know, ask the Gnus guys.  I just use `F` to follow up on a
message and trust in that Gnus does the right thing.

Bye,
Tassilo

Re: Gnus & Mail-Followup-To

[Nicolas Richard]

Tassilo Horn <tsdh@gnu.org> writes:
> Nicolas Richard <youngfrog@members.fsf.org> writes:
>> I saw that you have set :
>> Mail-Followup-To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
>> 	<monnier@iro.umontreal.ca>, nandryshak@gmail.com, nicolas@petton.fr,
>> 	emacs-devel@gnu.org
>>
>> FWIW, it made Gnus set Eli as recipient of my answer. Is it the intended
>> behaviour ?
>
> I don't know, ask the Gnus guys.

Sorry, I was unclear. My question to you was : is it what you intended
when you set the Mail-Followup-To header to the above value ? In
particular, you were not among the recipients anymore. Did you want to
avoid receiving a reply directly ?

>                                   I just use `F` to follow up on a
> message and trust in that Gnus does the right thing.

I usually do that too, and then this one time I decided to look at what
actually happens. I shouldn't do that obviously :)

There are a couple other things I should do (e.g. investigate why I
don't see some of my messages on gmane or why they show up slowly, why
some threads are broken, etc.). Usenetting/mailinglisting is hard :'(

-- 
Nico.

Re: Gnus & Mail-Followup-To

[Tassilo Horn]

Nicolas Richard <youngfrog@members.fsf.org> writes:

>>> I saw that you have set :
>>> Mail-Followup-To: Eli Zaretskii <eliz@gnu.org>, Stefan Monnier
>>> 	<monnier@iro.umontreal.ca>, nandryshak@gmail.com, nicolas@petton.fr,
>>> 	emacs-devel@gnu.org
>>>
>>> FWIW, it made Gnus set Eli as recipient of my answer. Is it the intended
>>> behaviour ?
>>
>> I don't know, ask the Gnus guys.
>
> Sorry, I was unclear.  My question to you was: is it what you intended
> when you set the Mail-Followup-To header to the above value ?  In
> particular, you were not among the recipients anymore. Did you want to
> avoid receiving a reply directly?

Yes, if possible.  And I have the configurations suggested by the Gnus
manual.

,----[ (info "(gnus)Group Parameters") ]
| ‘subscribed’
|      If this parameter is set to ‘t’, Gnus will consider the to-address
|      and to-list parameters for this group as addresses of mailing lists
|      you are subscribed to.  Giving Gnus this information is (only) a
|      first step in getting it to generate correct Mail-Followup-To
|      headers for your posts to these lists.  The second step is to put
|      the following in your ‘.gnus.el’
| 
|           (setq message-subscribed-address-functions
|                 '(gnus-find-subscribed-addresses))
| 
|      *Note Mailing Lists: (message)Mailing Lists, for a complete
|      treatment of available MFT support.
`----

So because Gnus knows I'm subscribed to emacs-devel, it didn't add
myself to the Mail-Followup-To header.

>> I just use `F` to follow up on a message and trust in that Gnus does
>> the right thing.
>
> I usually do that too, and then this one time I decided to look at
> what actually happens. I shouldn't do that obviously :)

Yeah, it's a sign you're losing faith!

> There are a couple other things I should do (e.g. investigate why I
> don't see some of my messages on gmane or why they show up slowly,

I'd guess that's a Gmane issue.

> why some threads are broken, 

Possibly a broken References header unless you gather threads by subject
(the variable `gnus-summary-thread-gathering-function' controls that).
And then you'll sometimes have multiple threads combined into one
because of equal subjects...

> etc.). Usenetting/mailinglisting is hard :'(

Yes, totally.  And it got worse when people started using the broken
mail clients available for tablets/smartphones.  In the good old days,
it has been simpler.  Gnus was correct, then there were clients which
were mostly correct, and then there was Outlook you could accurse for
always being wrong. ;-)

Bye,
Tassilo

Re: Gnus & Mail-Followup-To

[Nicolas Richard]

Tassilo Horn <tsdh@gnu.org> writes:
> Nicolas Richard <youngfrog@members.fsf.org> writes:
>>                                                        Did you want
>> to avoid receiving a reply directly?
>
> Yes, if possible.

Ok ! And  thanks for the other explanations.

>                          then there was Outlook you could accurse for
> always being wrong. ;-)

:)

--  
Nico.

Re: string> missing?

[Thierry Volpiatto]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Apply this same logic to string< and string>.
>
> Emacs is inconsistent.  That's part of its inheritance.
> If someone wants to add string>, I'm perfectly OK with it.
> But I'm surprised noone is arguing here in favor of dropping string< and
> making < and > accept strings instead!

I don't care of string>, I can live without, but note that adding it is
a very small work while removing string< will give you (and all external
packages maintainers) a big work to replace all occurences of string<,
IOW you will break many packages.
So do whatever you want but please don't remove string<.

Thanks.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: string> missing?

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]


Stefan Monnier writes:

>> Apply this same logic to string< and string>.
>
> Emacs is inconsistent.  That's part of its inheritance.
> If someone wants to add string>, I'm perfectly OK with it.

I'll do that.

> But I'm surprised noone is arguing here in favor of dropping string< and
> making < and > accept strings instead!

Yes, I thought about it, but then I wondered if that could be confusing,
being so different from what < currently is.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: string> missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I decided to define string< and not string> back when keeping Emacs
small was a major design goal.  Even one additional function was worth
avoiding.  I considered > so basic that it was worth adding, but
string> we could live without.

That goal no longer exists.  I see no harm in adding string> for
symmetry, now.
-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: string> missing?

[Eli Zaretskii]

> Date: Wed, 03 Jun 2015 17:24:44 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, nicolas@petton.fr, emacs-devel@gnu.org, tsdh@gnu.org
> 
> I decided to define string< and not string> back when keeping Emacs
> small was a major design goal.  Even one additional function was worth
> avoiding.  I considered > so basic that it was worth adding, but
> string> we could live without.
> 
> That goal no longer exists.  I see no harm in adding string> for
> symmetry, now.

You say that this goal no longer exists, but the practice of Emacs
maintenance tells me otherwise.  We are still making optimization
changes, some of them quite deep and pervasive ones, for very little
benefits, like a few percents decrease in memory footprint or in CPU
usage, even under the most favorable conditions.  In some cases, we
are prepared to pay dearly for such changes in obfuscating the code
with tricky multi-tiered macros, and in complicating the code and
making it harder to understand and maintain.

So it looks like making Emacs as small and as fast as humanly possible
is still very much a goal we want to pursue and are ready to pay for,
and therefore addition of convenience functions should be considered
with care, on a case by case basis.  If it's no longer a goal, we
should state that loud and clear, and start rejecting optimization-
related changes that fail to produce tangible gains, say, at least 10%
or 15%.

Re: string> missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > You say that this goal no longer exists, but the practice of Emacs
  > maintenance tells me otherwise.  We are still making optimization
  > changes, some of them quite deep and pervasive ones, for very little
  > benefits, like a few percents decrease in memory footprint or in CPU
  > usage, even under the most favorable conditions.

Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.

A few percent decrease could be a megabyte.  That big a space saving is
still worth something.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: string> missing?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 05 Jun 2015 13:56:14 -0400
> Cc: nicolas@petton.fr, tsdh@gnu.org, nandryshak@gmail.com, emacs-devel@gnu.org
> 
>   > You say that this goal no longer exists, but the practice of Emacs
>   > maintenance tells me otherwise.  We are still making optimization
>   > changes, some of them quite deep and pervasive ones, for very little
>   > benefits, like a few percents decrease in memory footprint or in CPU
>   > usage, even under the most favorable conditions.
> 
> Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.

It was also insignificant back when you decided not to include it.

Re: string> missing?

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>>   > You say that this goal no longer exists, but the practice of Emacs
>>   > maintenance tells me otherwise.  We are still making optimization
>>   > changes, some of them quite deep and pervasive ones, for very little
>>   > benefits, like a few percents decrease in memory footprint or in CPU
>>   > usage, even under the most favorable conditions.
>> 
>> Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.
>
> It was also insignificant back when you decided not to include it.

Adding string> to Emacs proper is maybe additional 200 bytes but may
save a multiple of its size when packages start using it instead of
defining their own version each.  For example, there are already
gnus-string>, org-string>, and also org-string>=.  And there are also
quite many lambdas implementing string>, e.g., in emacs/lisp/help.el, so
the addition of string> can in fact reduce the Emacs footprint if it
gets used there.

Bye,
Tassilo

Re: string> missing?

[Ivan Shmakov]

>>>>> Tassilo Horn <tsdh@gnu.org> writes:
>>>>> Eli Zaretskii <eliz@gnu.org> writes:

 >>> Adding string> might be 200 bytes.  Saving 200 bytes is
 >>> insignificant.

 >> It was also insignificant back when you decided not to include it.

 > Adding string> to Emacs proper is maybe additional 200 bytes but may
 > save a multiple of its size when packages start using it instead of
 > defining their own version each.  For example, there are already
 > gnus-string>, org-string>, and also org-string>=.  And there are also
 > quite many lambdas implementing string>, e.g., in emacs/lisp/help.el,
 > so the addition of string> can in fact reduce the Emacs footprint if
 > it gets used there.

	Then again, introducing string> in version X of Emacs means that
	all these packages are still bound to carry their own versions
	until their respective maintainers decide to drop support for
	pre-X Emacs versions.

-- 
FSF associate member #7257  http://am-1.org/~ivan/      … 3013 B6A0 230E 334A

Re: string> missing?

[Tassilo Horn]

Ivan Shmakov <ivan@siamics.net> writes:

>  > Adding string> to Emacs proper is maybe additional 200 bytes but may
>  > save a multiple of its size when packages start using it instead of
>  > defining their own version each.  For example, there are already
>  > gnus-string>, org-string>, and also org-string>=.  And there are also
>  > quite many lambdas implementing string>, e.g., in emacs/lisp/help.el,
>  > so the addition of string> can in fact reduce the Emacs footprint if
>  > it gets used there.
>
> 	Then again, introducing string> in version X of Emacs means that
> 	all these packages are still bound to carry their own versions
> 	until their respective maintainers decide to drop support for
> 	pre-X Emacs versions.

Yes, of course.  But the lambda in emacs/lisp/help.el can be replaced
just now, and then the addition of string> is at least a zero sum game.

Bye,
Tassilo

Re: string> missing?

[Tassilo Horn]

Tassilo Horn <tsdh@gnu.org> writes:

>> 	Then again, introducing string> in version X of Emacs means that
>> 	all these packages are still bound to carry their own versions
>> 	until their respective maintainers decide to drop support for
>> 	pre-X Emacs versions.
>
> Yes, of course.  But the lambda in emacs/lisp/help.el can be replaced
> just now, and then the addition of string> is at least a zero sum game.

Done!

Bye,
Tassilo

Re: string> missing?

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: rms@gnu.org,  nicolas@petton.fr,  nandryshak@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 05 Jun 2015 22:40:48 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >>   > You say that this goal no longer exists, but the practice of Emacs
> >>   > maintenance tells me otherwise.  We are still making optimization
> >>   > changes, some of them quite deep and pervasive ones, for very little
> >>   > benefits, like a few percents decrease in memory footprint or in CPU
> >>   > usage, even under the most favorable conditions.
> >> 
> >> Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.
> >
> > It was also insignificant back when you decided not to include it.
> 
> Adding string> to Emacs proper is maybe additional 200 bytes but may
> save a multiple of its size when packages start using it instead of
> defining their own version each.  For example, there are already
> gnus-string>, org-string>, and also org-string>=.  And there are also
> quite many lambdas implementing string>, e.g., in emacs/lisp/help.el, so
> the addition of string> can in fact reduce the Emacs footprint if it
> gets used there.

All of that was true back when Richard made his decision.

Re: string> missing?

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > It was also insignificant back when you decided not to include it.
>> 
>> Adding string> to Emacs proper is maybe additional 200 bytes but may
>> save a multiple of its size when packages start using it instead of
>> defining their own version each.  For example, there are already
>> gnus-string>, org-string>, and also org-string>=.  And there are also
>> quite many lambdas implementing string>, e.g., in emacs/lisp/help.el, so
>> the addition of string> can in fact reduce the Emacs footprint if it
>> gets used there.
>
> All of that was true back when Richard made his decision.

It would seem that today there are more packages bundled in emacs and
the typical user is more likely of using a good dozen of addon packages,
so the chances of re-uses of a function like string> effectively
reducing the size of a complete emacs install might be larger.

Bye,
Tassilo

Re: string> missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Adding string> to Emacs proper is maybe additional 200 bytes but may
  > > save a multiple of its size when packages start using it instead of
  > > defining their own version each.  For example, there are already
  > > gnus-string>, org-string>, and also org-string>=.  And there are also
  > > quite many lambdas implementing string>, e.g., in emacs/lisp/help.el, so
  > > the addition of string> can in fact reduce the Emacs footprint if it
  > > gets used there.

  > All of that was true back when Richard made his decision.

Those definitions did not exist in 1985.  And on the very small machine,
you could not load such big Lisp programs; they would not fit.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: string> missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.

  > It was also insignificant back when you decided not to include it.

With all due respect, I don't think you are in a position to judge.
You were not around when I worked hard to make GNU Emacs usable in a
machine with a rather low limit on the memory for a process.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: string> missing?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 05 Jun 2015 21:52:46 -0400
> Cc: nicolas@petton.fr, emacs-devel@gnu.org, nandryshak@gmail.com, tsdh@gnu.org
> 
>   > > Adding string> might be 200 bytes.  Saving 200 bytes is insignificant.
> 
>   > It was also insignificant back when you decided not to include it.
> 
> With all due respect, I don't think you are in a position to judge.

I'm just saying something that seemed to be a non-brainer.

If 200 bytes were significant back then, perhaps you could elaborate
on why and how it could be significant.  Then we all will be on the
same page.

TIA

Re: string> missing?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I'm just saying something that seemed to be a non-brainer.

200 bytes saved here, and 1000 bytes saved there, etc., added up to
savings of tens of k.  That meant more space for the user's files
and Lisp code.

I think the process memory limit was much less than a meg.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.