prin1 / princ vs message ?

prin1 / princ vs message ?

[Jean-Christophe Helary]

What's the difference between:

(let ((name "JC"))
  (prin1 "My name ")
  (princ " is ")
  (princ name)
  (princ ".\n\n"))

and

(message "My name is %s.\n\n" "JC")

?

Unless we have a non default value for standard-output both send the value to the echo area, right ?

Besides for the possibility prin1 and princ have of printing to standard-output and not specifically to the echo area, what is the actual difference between the two and message ?

Jean-Christophe 

Re: prin1 / princ vs message ?

[Tino Calancha]

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



On Sun, 2 Jul 2017, Jean-Christophe Helary wrote:

> What's the difference between:
>
> (let ((name "JC"))
>  (prin1 "My name ")
>  (princ " is ")
>  (princ name)
>  (princ ".\n\n"))
>
> and
>
> (message "My name is %s.\n\n" "JC")
>
> ?
>
> Unless we have a non default value for standard-output both send the value to the echo area, right ?
>
> Besides for the possibility prin1 and princ have of printing to standard-output and not specifically to the echo area, what is the actual difference between the two and message ?

* Documentation about prin? family:
(info "(elisp) Output Functions")

* "The recommended way to show a message in the echo area is with the
   `message' function, not `princ’".
   Extracted from:
(info "(elisp) Programming Tips")

* `message' and the echo area:
(info "(elisp) The Echo Area")

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

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


> On Jul 2, 2017, at 20:57, Tino Calancha <tino.calancha@gmail.com> wrote:
> 
>> What's the difference between:
>> 
>> (let ((name "JC"))
>> (prin1 "My name ")
>> (princ " is ")
>> (princ name)
>> (princ ".\n\n"))
>> 
>> and
>> 
>> (message "My name is %s.\n\n" "JC")
>> 
>> ?
>> 
>> Unless we have a non default value for standard-output both send the value to the echo area, right ?
>> 
>> Besides for the possibility prin1 and princ have of printing to standard-output and not specifically to the echo area, what is the actual difference between the two and message ?
> 
> * Documentation about prin? family:
> (info "(elisp) Output Functions")
> 
> * "The recommended way to show a message in the echo area is with the
>  `message' function, not `princ’".
>  Extracted from:
> (info "(elisp) Programming Tips")
> 
> * `message' and the echo area:
> (info "(elisp) The Echo Area")

Tino,

I think that was pretty clear that I had actually read the documentation about prin1, princ and message. So let me reiterate:

I am asking that because I am seeing code where standard-output is not set to anything but it's default (the echo area) and still prin1/princ are preferred over message. So, why would a developer chose prin1/princ over message when there is no stream argument (hence, when the output goes to standard output).

The documentation seems to imply that message should be preferred, but are there cases where prin1/princ are the best choice ?

Jean-Christophe 

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

Re: prin1 / princ vs message ?

[Andreas Schwab]

print etc are standard lisp functions, intended for noninteractive use.

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: prin1 / princ vs message ?

[Jean-Christophe Helary]

> On Jul 2, 2017, at 21:32, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> print etc are standard lisp functions, intended for noninteractive use.

Thank you. So what would be the practical reason why a developer would prefer:

(let ((name "JC"))
 (prin1 "My name ")
 (princ " is ")
 (princ name)
 (princ ".\n\n"))

over:

(message "My name is %s.\n\n" "JC")

when standard-input is not set to anything special?

(I'm almost copying the above code verbatim from a package in emacs.)

Jean-Christophe

Re: prin1 / princ vs message ?

[Tino Calancha]

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



On Sun, 2 Jul 2017, Jean-Christophe Helary wrote:

> * Documentation about prin? family:
> (info "(elisp) Output Functions")
> 
> * "The recommended way to show a message in the echo area is with the
>  `message' function, not `princ’".
>  Extracted from:
> (info "(elisp) Programming Tips")
> 
> * `message' and the echo area:
> (info "(elisp) The Echo Area")
> 
> 
> Tino,
> 
> I think that was pretty clear that I had actually read the documentation about prin1, princ and message. So let me reiterate:
Appologies,  i misunderstood that.
> 
> I am asking that because I am seeing code where standard-output is not set to anything but it's default (the echo area) and still
> prin1/princ are preferred over message. So, why would a developer chose prin1/princ over message when there is no stream argument
> (hence, when the output goes to standard output).
> 
> The documentation seems to imply that message should be preferred, but are there cases where prin1/princ are the best choice ?
In my case i use `message' most of the time.
I just use `prin?' things when i want to insert the printable 
representation of a lisp object withing a buffer.  Not so often, though.

In files, like
international/quail.el
or
international/mule-diag.el

note that they use the macro `with-output-to-temp-buffer', so they
must use `prin?' instead of `message' to collect the standard-output.

Even when `with-output-to-temp-buffer' is not called explicitely in
the file, like in
lisp/cus-theme.el

you better use `prin?' there, because those are messages related with
the Emacs help, i mean, they will appear in *Help* buffers which
are build binding standard-output.

Other than that i would stick with `message'.

Re: prin1 / princ vs message ?

[Noam Postavsky]

On Sun, Jul 2, 2017 at 8:21 AM, Jean-Christophe Helary
<jean.christophe.helary@gmail.com> wrote:
>
> I am asking that because I am seeing code where standard-output is not set
> to anything but it's default (the echo area) and still prin1/princ are
> preferred over message. So, why would a developer chose prin1/princ over
> message when there is no stream argument (hence, when the output goes to
> standard output).

Using prin1/princ lets the caller let-bind standard-output to redirect
the output elsewhere, using message would not allow this.

Otherwise, I think the only practical difference is that prin1/princ
to the echo area doesn't support message coalescing, e.g.,
(progn (message "foo") (message "foo")) will show "foo [2 times]" in
*Messages*, whereas (progn (princ "foo") (princ "foo")) will show
"foofoo".

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

Tony, Noam,

Thank you very much for the clarifications.

So, since I expect the developer to know the difference between the prin? collection and message could you tell me if the following is correct:

Instead of using message to replace that code:

(let ((name "JC"))
(prin1 "My name ")
(princ " is ")
(princ name)
(princ ".\n\n"))

It would be better to use something like:

(let ((sentence (format "My name is %s.\n\n)))
     (prin1 sentence))

That way I keep the possibility to redirect the output somewhere else while making the sentence actually maintainable...

Jean-Christophe

> On Jul 2, 2017, at 21:45, Noam Postavsky <npostavs@users.sourceforge.net> wrote:
> 
> On Sun, Jul 2, 2017 at 8:21 AM, Jean-Christophe Helary
> <jean.christophe.helary@gmail.com> wrote:
>> 
>> I am asking that because I am seeing code where standard-output is not set
>> to anything but it's default (the echo area) and still prin1/princ are
>> preferred over message. So, why would a developer chose prin1/princ over
>> message when there is no stream argument (hence, when the output goes to
>> standard output).
> 
> Using prin1/princ lets the caller let-bind standard-output to redirect
> the output elsewhere, using message would not allow this.
> 
> Otherwise, I think the only practical difference is that prin1/princ
> to the echo area doesn't support message coalescing, e.g.,
> (progn (message "foo") (message "foo")) will show "foo [2 times]" in
> *Messages*, whereas (progn (princ "foo") (princ "foo")) will show
> "foofoo".

Re: prin1 / princ vs message ?

[Noam Postavsky]

On Sun, Jul 2, 2017 at 9:09 AM, Jean-Christophe Helary
<jean.christophe.helary@gmail.com> wrote:

> (let ((sentence (format "My name is %s.\n\n)))
>      (prin1 sentence))

That looks nicer yes, but your example mixes between prin1 and princ
(so the output of each piece of code is slightly different), is that
on purpose? `princ' output is like the %s format, whereas `prin1'
output is like the %S format.

Re: prin1 / princ vs message ?

[Tino Calancha]

On Sun, 2 Jul 2017, Jean-Christophe Helary wrote:

> Tony, Noam,
>
> Thank you very much for the clarifications.
>
> So, since I expect the developer to know the difference between the prin? collection and message could you tell me if the following is correct:
>
> Instead of using message to replace that code:
>
> (let ((name "JC"))
> (prin1 "My name ")
> (princ " is ")
> (princ name)
> (princ ".\n\n"))
>
> It would be better to use something like:
>
> (let ((sentence (format "My name is %s.\n\n)))
>     (prin1 sentence))
>
> That way I keep the possibility to redirect the output somewhere else while making the sentence actually maintainable...
That's sounds pretty OK.
I would just modify a bit your example, because currenty doesn't work,
you get the error:
read-from-minibuffer: End of file during parsing

The following must work:
(let ((sentence
        (format "My name is %s.\n\n"
                "Tino, but often people call me Tony.  Who cares? :-)")))
   (prin1 sentence))

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

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


> On Jul 2, 2017, at 22:21, Tino Calancha <tino.calancha@gmail.com> wrote:
> 
>> Instead of using message to replace that code:
>> 
>> (let ((name "JC"))
>> (prin1 "My name ")
>> (princ " is ")
>> (princ name)
>> (princ ".\n\n"))
>> 
>> It would be better to use something like:
>> 
>> (let ((sentence (format "My name is %s.\n\n)))
>>    (prin1 sentence))
>> 
>> That way I keep the possibility to redirect the output somewhere else while making the sentence actually maintainable...
> That's sounds pretty OK.
> I would just modify a bit your example, because currenty doesn't work,
> you get the error:
> read-from-minibuffer: End of file during parsing

Yes, I just realized that I had forgotten a lot of required stuff :) Sorry.

As for Noam's question, the mixing is, I guess, intended but was not properly reflected in my example:

(let ((name "JC"))
(princ "My name ")
(princ " is ")
(prin1 name)
(princ ".\n\n"))


Jean-Christophe 

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

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

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

Conclusion of that exchange (sorry for being a little slow to understand everything the 3 of you wrote):

This:
    (prin1 name)
    (princ " is ")
    (princ (if (memq (aref status 0) '(?a ?e ?i ?o ?u)) "an " "a "))
    (princ status)
    (princ " package.\n\n")

Can reasonably be replaced by this:
    (let (sentence (format "The status of package %1$S is `%2$s'.\n\n" name status)))
    (princ sentence))

Is that correct ? (I am using the numbered fields that Philipp Stephani implemented in June.) 

Jean-Christophe

> On Jul 2, 2017, at 22:47, Jean-Christophe Helary <jean.christophe.helary@gmail.com> wrote:
> 
> 
>> On Jul 2, 2017, at 22:21, Tino Calancha <tino.calancha@gmail.com <mailto:tino.calancha@gmail.com>> wrote:
>> 
>>> Instead of using message to replace that code:
>>> 
>>> (let ((name "JC"))
>>> (prin1 "My name ")
>>> (princ " is ")
>>> (princ name)
>>> (princ ".\n\n"))
>>> 
>>> It would be better to use something like:
>>> 
>>> (let ((sentence (format "My name is %s.\n\n)))
>>>    (prin1 sentence))
>>> 
>>> That way I keep the possibility to redirect the output somewhere else while making the sentence actually maintainable...
>> That's sounds pretty OK.
>> I would just modify a bit your example, because currenty doesn't work,
>> you get the error:
>> read-from-minibuffer: End of file during parsing
> 
> Yes, I just realized that I had forgotten a lot of required stuff :) Sorry.
> 
> As for Noam's question, the mixing is, I guess, intended but was not properly reflected in my example:
> 
> (let ((name "JC"))
> (princ "My name ")
> (princ " is ")
> (prin1 name)
> (princ ".\n\n"))
> 
> 
> Jean-Christophe 


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

Re: prin1 / princ vs message ?

[Tino Calancha]

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



On Sun, 2 Jul 2017, Jean-Christophe Helary wrote:

> Conclusion of that exchange (sorry for being a little slow to understand everything the 3 of you wrote):
> 
> This:
>     (prin1 name)
>     (princ " is ")
>     (princ (if (memq (aref status 0) '(?a ?e ?i ?o ?u)) "an " "a "))
>     (princ status)
>     (princ " package.\n\n")
> 
> Can reasonably be replaced by this:
>     (let (sentence (format "The status of package %1$S is `%2$s'.\n\n" name status)))
>     (princ sentence))
> 
> Is that correct ? (I am using the numbered fields that Philipp Stephani implemented in June.) 
Yeah, it looks right.

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

Thank you very much Tino (I did actually call you Tony didn't I... :-)

Jean-Christophe

> On Jul 2, 2017, at 23:23, Tino Calancha <tino.calancha@gmail.com> wrote:
> 
> 
> 
> On Sun, 2 Jul 2017, Jean-Christophe Helary wrote:
> 
>> Conclusion of that exchange (sorry for being a little slow to understand everything the 3 of you wrote):
>> This:
>>     (prin1 name)
>>     (princ " is ")
>>     (princ (if (memq (aref status 0) '(?a ?e ?i ?o ?u)) "an " "a "))
>>     (princ status)
>>     (princ " package.\n\n")
>> Can reasonably be replaced by this:
>>     (let (sentence (format "The status of package %1$S is `%2$s'.\n\n" name status)))
>>     (princ sentence))
>> Is that correct ? (I am using the numbered fields that Philipp Stephani implemented in June.) 
> Yeah, it looks right.

Re: prin1 / princ vs message ?

[Philipp Stephani]

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

Jean-Christophe Helary <jean.christophe.helary@gmail.com> schrieb am So.,
2. Juli 2017 um 16:03 Uhr:

> Conclusion of that exchange (sorry for being a little slow to understand
> everything the 3 of you wrote):
>
> This:
>     (prin1 name)
>     (princ " is ")
>     (princ (if (memq (aref status 0) '(?a ?e ?i ?o ?u)) "an " "a "))
>     (princ status)
>     (princ " package.\n\n")
>
> Can reasonably be replaced by this:
>     (let (sentence (format "The status of package %1$S
> is `%2$s'.\n\n" name status)))
>     (princ sentence))
>
> Is that correct ?
>

You should probably use `format-message' instead of `format' here.
`format-message' is for messages displayed to the user, and I'd imagine
when introducing localization you'd integrate it only with
`format-message', not `format'.

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

Re: prin1 / princ vs message ?

[Jean-Christophe Helary]

> On Jul 2, 2017, at 23:27, Philipp Stephani <p.stephani2@gmail.com> wrote:
> 
> You should probably use `format-message' instead of `format' here. `format-message' is for messages displayed to the user, and I'd imagine when introducing localization you'd integrate it only with `format-message', not `format'. 

I see. Right now there are user facing messages that use a lot of different functions and it would be a lot of work to convert them all to a format-message structure. But I'll keep your remark as reference for the (hopefully near) future.

Thank you.

Jean-Christophe

(format "Hello %1$S%2$s" 'world "!")

[Clément Pit-Claudel]

On 2017-07-02 10:02, Jean-Christophe Helary wrote:
> (I am using the numbered fields that Philipp Stephani implemented in June.) 

Hm, this patch went through?  I thought there were still disagreements about the syntax.

Did we consider introducing a new formatting function (with a polyfill for older Emacsen), rather than this %n$ syntax?

Clément.

Re: (format "Hello %1$S%2$s" 'world "!")

[Jean-Christophe Helary]

> On Jul 2, 2017, at 23:30, Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
> 
> On 2017-07-02 10:02, Jean-Christophe Helary wrote:
>> (I am using the numbered fields that Philipp Stephani implemented in June.) 
> 
> Hm, this patch went through?

According to Eli's message today (i18n/l10n summary thread), yes.

Jean-Christophe 

>  I thought there were still disagreements about the syntax.
> 
> Did we consider introducing a new formatting function (with a polyfill for older Emacsen), rather than this %n$ syntax?
> 
> Clément.
> 

Re: (format "Hello %1$S%2$s" 'world "!")

[Noam Postavsky]

On Sun, Jul 2, 2017 at 10:30 AM, Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
> On 2017-07-02 10:02, Jean-Christophe Helary wrote:
>> (I am using the numbered fields that Philipp Stephani implemented in June.)
>
> Hm, this patch went through?  I thought there were still disagreements about the syntax.

There were some tweaks following the initial patch, but I don't recall
any major disagreements about syntax. I posted some relevant links in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12777#8

> Did we consider introducing a new formatting function (with a polyfill for older Emacsen), rather than this %n$ syntax?

I don't recall anyone suggesting that. Why would we need a new
function since %n$ would be an error for the old format anyway?

Re: (format "Hello %1$S%2$s" 'world "!")

[Clément Pit-Claudel]

On 2017-07-02 11:03, Noam Postavsky wrote:
> I don't recall anyone suggesting that. 

Sorry, I should have, then :/

> Why would we need a new function since %n$ would be an error for the old format anyway?

This in itself is a good reason to have a new function.  A new function lets you migrate existing code, including plugins, to the new syntax, and load the polyfill in older Emacsen.  A new syntax that causes errors in old Emacsen isn't usable by anyone outside of Emacs core, for fear of compatibility problems.

Also, the syntax is very heavy.  Was it inspired by another programming language?  The ones I'm familiar with use $1, {1}, or similar syntax, but I've never seen %1$s :/

Re: (format "Hello %1$S%2$s" 'world "!")

[Noam Postavsky]

On Sun, Jul 2, 2017 at 12:32 PM, Clément Pit-Claudel
<cpitclaudel@gmail.com> wrote:
>> Why would we need a new function since %n$ would be an error for the old format anyway?
>
> This in itself is a good reason to have a new function.  A new function lets you migrate existing code, including plugins, to the new syntax, and load the polyfill in older Emacsen.  A new syntax that causes errors in old Emacsen isn't usable by anyone outside of Emacs core, for fear of compatibility problems.

We can still give a new name I suppose.

> The ones I'm familiar with use $1, {1}, or similar syntax,

What's the equivalent of %1$d in that syntax? Or is it just strings?

> but I've never seen %1$s :/

It's a POSIX extension to C's printf [1,2], also used by Java [3] and perl [4].

[1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
[2]: https://en.wikipedia.org/wiki/Printf_format_string
[3]: https://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
[4]: https://perldoc.perl.org/functions/sprintf.html

Re: (format "Hello %1$S%2$s" 'world "!")

[Clément Pit-Claudel]

On 2017-07-02 12:54, Noam Postavsky wrote:
> On Sun, Jul 2, 2017 at 12:32 PM, Clément Pit-Claudel
> <cpitclaudel@gmail.com> wrote:
>>> Why would we need a new function since %n$ would be an error for the old format anyway?
>>
>> This in itself is a good reason to have a new function.  A new function lets you migrate existing code, including plugins, to the new syntax, and load the polyfill in older Emacsen.  A new syntax that causes errors in old Emacsen isn't usable by anyone outside of Emacs core, for fear of compatibility problems.
> 
> We can still give a new name I suppose.

I think it would be nice, if we also write a polyfill. If we don't intend to write one, then there's probably no point.

>> The ones I'm familiar with use $1, {1}, or similar syntax,
> 
> What's the equivalent of %1$d in that syntax? Or is it just strings?

{1:d} (this one is Python).

>> but I've never seen %1$s :/
> 
> It's a POSIX extension to C's printf [1,2], also used by Java [3] and perl [4].
> 
> [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/printf.html
> [2]: https://en.wikipedia.org/wiki/Printf_format_string
> [3]: https://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
> [4]: https://perldoc.perl.org/functions/sprintf.html

Then I guess it's good enough :) Maybe I just need to get used to that syntax.

Clément.

Re: (format "Hello %1$S%2$s" 'world "!")

[Philipp Stephani]

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

Clément Pit-Claudel <cpitclaudel@gmail.com> schrieb am So., 2. Juli 2017 um
19:26 Uhr:

> On 2017-07-02 12:54, Noam Postavsky wrote:
> > On Sun, Jul 2, 2017 at 12:32 PM, Clément Pit-Claudel
> > <cpitclaudel@gmail.com> wrote:
> >>> Why would we need a new function since %n$ would be an error for the
> old format anyway?
> >>
> >> This in itself is a good reason to have a new function.  A new function
> lets you migrate existing code, including plugins, to the new syntax, and
> load the polyfill in older Emacsen.  A new syntax that causes errors in old
> Emacsen isn't usable by anyone outside of Emacs core, for fear of
> compatibility problems.
> >
> > We can still give a new name I suppose.
>
> I think it would be nice, if we also write a polyfill. If we don't intend
> to write one, then there's probably no point.
>

We can't write a polyfill, just like browser developers can't write
polyfills (if they do so, it's just normal functionality).
Third-party library authors can write polyfills, of course, if they want.

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

Re: (format "Hello %1$S%2$s" 'world "!")

[Vivek Dasmohapatra]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 785 bytes --]

> Also, the syntax is very heavy.  Was it inspired by another programming 
> language?  The ones I'm familiar with use $1, {1}, or similar syntax, but 
> I've never seen %1$s :/

From printf(3):

   By default, the arguments are used in the order given, …
   One can also specify explicitly which argument is taken, at each place
   where an argument is required, by writing "%m$" instead of '%' and "*m$"
   instead of '*', where the decimal integer m denotes the position in the
   argument list of the desired argument, indexed starting from 1.  Thus,

        printf("%*d", width, num);
        and
        printf("%2$*1$d", width, num);

https://en.wikipedia.org/wiki/Printf_format_string#Parameter_field

I don't know when POSIX introduced it, but it's been around for a while.

Re: (format "Hello %1$S%2$s" 'world "!")

[Philipp Stephani]

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

Clément Pit-Claudel <cpitclaudel@gmail.com> schrieb am So., 2. Juli 2017 um
18:34 Uhr:

> On 2017-07-02 11:03, Noam Postavsky wrote:
>
> > Why would we need a new function since %n$ would be an error for the old
> format anyway?
>
> This in itself is a good reason to have a new function.  A new function
> lets you migrate existing code, including plugins, to the new syntax, and
> load the polyfill in older Emacsen.  A new syntax that causes errors in old
> Emacsen isn't usable by anyone outside of Emacs core, for fear of
> compatibility problems.
>

We extend functions all the time. Here's a random entry from NEWS:

*** Time conversion functions now accept an optional ZONE argument
that specifies the time zone rules for conversion.  ZONE is omitted or
nil for Emacs local time, t for Universal Time, 'wall' for system wall
clock time, or a string as in the TZ environment variable.  The
affected functions are 'current-time-string', 'current-time-zone',
'decode-time', and 'format-time-string'.  The function 'encode-time',
which already accepted a simple time zone rule argument, has been
extended to accept all the new forms.

There's no difference between those changes and this one: the new syntax
was an error before, but now has a specified meaning.


>
> Also, the syntax is very heavy.  Was it inspired by another programming
> language?  The ones I'm familiar with use $1, {1}, or similar syntax, but
> I've never seen %1$s :/
>
>
As said, it comes from GNU printf.
We need to use a syntax that's backwards-compatible, that rules out $1 or
{1}.

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

Re: (format "Hello %1$S%2$s" 'world "!")

[Philipp Stephani]

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

Clément Pit-Claudel <cpitclaudel@gmail.com> schrieb am So., 2. Juli 2017 um
16:31 Uhr:

> On 2017-07-02 10:02, Jean-Christophe Helary wrote:
> > (I am using the numbered fields that Philipp Stephani implemented in
> June.)
>
> Hm, this patch went through?  I thought there were still disagreements
> about the syntax.
>

Not that I'm aware of. The syntax is pretty much fixed by the behavior of
GNU printf.


>
> Did we consider introducing a new formatting function (with a polyfill for
> older Emacsen), rather than this %n$ syntax?
>

No, there's no need for that: the syntax extension is backward-compatible.

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

Re: prin1 / princ vs message ?

[Stefan Monnier]

> Besides for the possibility prin1 and princ have of printing to
> standard-output and not specifically to the echo area, what is the actual
> difference between the two and message ?

AFAIK the difference is that `message` knows a lot more about the
*intention* of the code (to display some informative the text as one
message to the user in the echo area, presumably related to something
that happened very recently), whereas princ/prin1 is not specific to the
echo area (e.g. doesn't know that it's meant to be displayed) and
doesn't know when the message starts and ends.

So I'd expect different behavior w.r.t message logging, or w.r.t
interaction between competing uses of the miniwindow (such as plain
`message`s, minibuffer input, eldoc, etc...), ...


        Stefan