(unknown)

(unknown)

[Eli Zaretskii]

Dmitry, could you please explain the reason(s) for the change below?

Vertical positions in a window can never be large enough to justify
using ptrdiff_t (on platforms where that is wider than a 32-bit
'int').  These are pixel positions on the Emacs display, so they
cannot be too large.  The type of 'first_vpos' looks especially
strange, since it is explicitly set to 1 at most.  I'm not aware of a
platform where an 'int' is not wide enough for a value 1 ;-)

Using inappropriate data types makes the code harder to read and
understand, because it hints that something non-obvious is going on
somewhere.

	 * xdisp.c (try_window_id): Change type of 'first_vpos' and 'vpos'
	 to ptrdiff_t.

  --- src/xdisp.c 2012-06-28 12:29:37 +0000
  +++ src/xdisp.c 2012-06-29 11:48:08 +0000
  @@ -17761,8 +17761,8 @@ try_window_id (struct window *w)
       {
	 /* Displayed to end of window, but no line containing text was
	   displayed.  Lines were deleted at the end of the window.  */
  -      int first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  -      int vpos = XFASTINT (w->window_end_vpos);
  +      ptrdiff_t first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  +      ptrdiff_t vpos = XFASTINT (w->window_end_vpos);
	 struct glyph_row *current_row = current_matrix->rows + vpos;
	 struct glyph_row *desired_row = desired_matrix->rows + vpos;

ptrdiff_t misuse [was :Re: (empty)]

[Dmitry Antipov]

On 06/29/2012 05:20 PM, Eli Zaretskii wrote:

> Dmitry, could you please explain the reason(s) for the change below?
>
> Vertical positions in a window can never be large enough to justify
> using ptrdiff_t (on platforms where that is wider than a 32-bit
> 'int').  These are pixel positions on the Emacs display, so they
> cannot be too large.  The type of 'first_vpos' looks especially
> strange, since it is explicitly set to 1 at most.  I'm not aware of a
> platform where an 'int' is not wide enough for a value 1 ;-)

Argh, I misuse them against window_end_pos and window_end_bytepos,
which are positions in a buffer and so ptrdiff_t :-(.  This should
be reverted.

Dmitry

Re: ptrdiff_t misuse [was :Re: (empty)]

[Stefan Monnier]

> Argh, I misuse them against window_end_pos and window_end_bytepos,
> which are positions in a buffer and so ptrdiff_t :-(.  This should
> be reverted.

Not only there: hscroll and min_hscroll should be `int' fields.
And similarly Paul's "fix" to use:

  ptrdiff_t clipped_arg
    = clip_to_bounds (- w->hscroll, requested_arg, HSCROLL_MAX - w->hscroll);

should be reverted.  Really, if someone ever bumps into a problem
because of such an overflow, I'll be *super* happy, because it means
that all the performance problems we get with long lines have
been fixed.

Properly catching/handling integer overflows is a good idea, but C makes
it much too painful in general, so we don't want to do it in
unrealistic corner cases, preferring code cleanliness.



        Stefan

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Fri, 29 Jun 2012 18:18:59 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> Argh, I misuse them against window_end_pos and window_end_bytepos,
> which are positions in a buffer and so ptrdiff_t :-(.  This should
> be reverted.

Done.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

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

On 06/29/2012 12:07 PM, Stefan Monnier wrote:
> if someone ever bumps into a problem
> because of such an overflow, I'll be*super*  happy, because it means
> that all the performance problems we get with long lines have
> been fixed.

No, if the overflow happens to generate a small integer,
Emacs will run quickly and incorrectly
without the patch in question.  Perhaps
there's a better fix, and certainly that area
of the code needs changing if hscroll
is changed to 'int' as suggested; but some fix
is needed.


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

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Sat, 30 Jun 2012 02:13:36 -0500
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, emacs-devel@gnu.org
> 
> if the overflow happens to generate a small integer, Emacs will run
> quickly and incorrectly without the patch in question.

But since this will _never_ happen in real life, the patch in question
is a net loss, because it obfuscates the code for no good reason.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Stefan Monnier]

>> if someone ever bumps into a problem
>> because of such an overflow, I'll be*super*  happy, because it means
>> that all the performance problems we get with long lines have
>> been fixed.
> No, if the overflow happens to generate a small integer,
> Emacs will run quickly and incorrectly
> without the patch in question.

But "fixing" the code like you have will just make it run "correctly"
and so super-extra slow that the user will just think it's frozen.
So, better keep the code clean since in any case it won't work,


        Stefan

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 06/30/2012 02:27 AM, Eli Zaretskii wrote:
> But since this will _never_ happen in real life

Surely this overflow can happen in real life, by putting the
proper strings into a text file that someone visits, which is
the sort of thing that a trickster would do.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 06/30/2012 07:07 AM, Stefan Monnier wrote:
> But "fixing" the code like you have will just make it run "correctly"
> and so super-extra slow that the user will just think it's frozen.

If Emacs simply cannot handle large hscroll values, how
about if we ceiling them out at some suitably-large value,
say 1000?  That would make this discussion moot and would
make Emacs more robust in practice, as it'd prevent some
freezes.  Emacs already limits tab width in this way, so
there's precedent.  I can work on writing up a patch along
these lines if you like.

If we can't impose an arbitrary limit, then here are some
more thoughts about the point at issue.

Although it's true that in some cases Emacs happened to run
incorrectly and quickly without the fix, in other cases
Emacs ran incorrectly and froze whereas it now runs
correctly and quickly (e.g., if the new hscroll is
sufficiently negative).  Since the patch fixes this bug
without introducing new bugs it seems like a win.

Besides, the previous paragraph assumes that signed integer
overflow silently wraps around.  This was formerly true of
Emacs porting targets but is no longer true: overflow has
undefined behavior, and can dump core or worse.  Maybe the
unfixed code happens to wrap around or dump core on all our
porting targets when overflow occurs (which appears to be
"acceptable" behavior here), but maybe it has even worse
behavior, and it's not feasible to test whether it does.
The fixed code doesn't have this problem.

I sense a larger worry here that if we methodically change
Emacs to prevent all cases of undefined behavior triggerable
by converting Emacs fixnums to C integer values, then we'll
have to add lots of checks that contort the C code so much
as to make Emacs unmaintainable.  If that's the worry, then
there should be no need for concern, as no rewrite should be
needed: the Emacs source code already has the desired
property, modulo whatever minor bugs in this area still need
fixing.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Stefan Monnier]

> If Emacs simply cannot handle large hscroll values, how

No, the problem is long lines.


        Stefan

Re: ptrdiff_t misuse [was :Re: (empty)]

[Stefan Monnier]

>> But since this will _never_ happen in real life
> Surely this overflow can happen in real life, by putting the
> proper strings into a text file that someone visits, which is
> the sort of thing that a trickster would do.

If it just causes a minor misbehavior, I'm not worried,


        Stefan

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 06/30/2012 07:23 AM, Stefan Monnier wrote:
> No, the problem is long lines.

There's also a problem even if lines are short.
I ran Emacs without the patch, on files with
only short lines, and attempted large horizontal
scroll values (say, most-positive-fixnum minus 100).
The screen would mess up.  Sometimes even after I
scrolled back to the left margin, there would be scroll
indicators in the left column.  Sometimes there would
be stray characters on the screen.

To work around this I pushed a patch (trunk bzr 108856)
that arbitrarily ceilings the hscroll value at 100000.
I didn't observe any problems with hscroll values less
than that, though I suppose the exact safe region may
vary depending on font sizes or whatnot.

This patch removes the PTRDIFF_MAX checks that
prompted this thread, as they're no longer needed.

This patch is independent of whether hscroll values
are stored as ptrdiff_t or EMACS_INT or int, so it
shouldn't affect Dmitry's work-in-progress that
would change the number of bits in an hscroll value.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Tue, 03 Jul 2012 23:25:26 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Dmitry Antipov <dmantipov@yandex.ru>, emacs-devel@gnu.org
> 
> On 06/30/2012 07:23 AM, Stefan Monnier wrote:
> > No, the problem is long lines.
> 
> There's also a problem even if lines are short.
> I ran Emacs without the patch, on files with
> only short lines, and attempted large horizontal
> scroll values (say, most-positive-fixnum minus 100).
> The screen would mess up.  Sometimes even after I
> scrolled back to the left margin, there would be scroll
> indicators in the left column.  Sometimes there would
> be stray characters on the screen.
> 
> To work around this I pushed a patch (trunk bzr 108856)
> that arbitrarily ceilings the hscroll value at 100000.

I'm quite sure this is the wrong fix, it just sweeps the problem under
the carpet.  My guess is that, when hscroll is close to INT_MAX, the
calculations in display_line, e.g. here:

  /* Move over display elements that are not visible because we are
     hscrolled.  This may stop at an x-position < IT->first_visible_x
     if the first glyph is partially visible or if we hit a line end.  */
  if (it->current_x < it->first_visible_x)
    {
      this_line_min_pos = row->start.pos;
      move_it_in_display_line_to (it, ZV, it->first_visible_x,
				  MOVE_TO_POS | MOVE_TO_X);

and in move_it_in_display_line_to this calls, overflow, because these
calculations are done in pixels, not in character cells, and so
typically (for the default font) manipulate values that are 10 times
larger than the hscroll value.

So to fix this in the right place, we need to limit the pixel
coordinates, not the character cell coordinates.

Feel free to fix the problem that way, or leave it to me.  But
revision 108856 should be reverted.

Thanks.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 07/04/2012 09:39 AM, Eli Zaretskii wrote:
> Feel free to fix the problem that way, or leave it to me.  But
> revision 108856 should be reverted.

OK, thanks, I reverted the arbitrary imposition of a limit of 100000
in the trunk, and filed Bug#11857 about the underlying problem.
The underlying problem is not new -- I reproduced it in Emacs 23.3 --
so at least this is not a regression.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Wed, 04 Jul 2012 11:19:12 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: monnier@iro.umontreal.ca, dmantipov@yandex.ru, emacs-devel@gnu.org
> 
> On 07/04/2012 09:39 AM, Eli Zaretskii wrote:
> > Feel free to fix the problem that way, or leave it to me.  But
> > revision 108856 should be reverted.
> 
> OK, thanks, I reverted the arbitrary imposition of a limit of 100000
> in the trunk, and filed Bug#11857 about the underlying problem.

Thanks, should be fixed now.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

Btw, what's the theory behind using ptrdiff_t in preference to
EMACS_INT to store values that came from Lisp?  E.g., in this snippet:

  static Lisp_Object
  set_window_hscroll (struct window *w, EMACS_INT hscroll)
  {
    ...
    ptrdiff_t hscroll_max = min (MOST_POSITIVE_FIXNUM, PTRDIFF_MAX);
    ptrdiff_t new_hscroll = clip_to_bounds (0, hscroll, hscroll_max);

Won't this do The Wrong Thing when Emacs is configured with wide ints?
It looks like EMACS_INT is always preferable in these contexts, as it
always has the right width.

Likewise for variables that store buffer or string positions.

What am I missing?

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 07/05/2012 12:34 PM, Eli Zaretskii wrote:
>     ptrdiff_t hscroll_max = min (MOST_POSITIVE_FIXNUM, PTRDIFF_MAX);
>     ptrdiff_t new_hscroll = clip_to_bounds (0, hscroll, hscroll_max);
> 
> Won't this do The Wrong Thing when Emacs is configured with wide ints?

No, because hscroll_max and new_hscroll cannot
exceed PTRDIFF_MAX (the above code guarantees
this directly), so their values therefore always fit
in ptrdiff_t range even when EMACS_INT is wider than
ptrdiff_t.

Similarly, buffer and string positions cannot exceed
BUF_BYTES_MAX and STRING_BYTES_MAX, which in turn
cannot exceed PTRDIFF_MAX; so ptrdiff_t always
suffices for them too.

If we change hscroll values from ptrdiff_t to int, as
I think Dmitry is proposing, the above code should be
changed to use int and INT_MAX instead of ptrdiff_t
and PTRDIFF_MAX.

Re: ptrdiff_t misuse [was :Re: (empty)]

[Eli Zaretskii]

> Date: Thu, 05 Jul 2012 17:08:50 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On 07/05/2012 12:34 PM, Eli Zaretskii wrote:
> >     ptrdiff_t hscroll_max = min (MOST_POSITIVE_FIXNUM, PTRDIFF_MAX);
> >     ptrdiff_t new_hscroll = clip_to_bounds (0, hscroll, hscroll_max);
> > 
> > Won't this do The Wrong Thing when Emacs is configured with wide ints?
> 
> No, because hscroll_max and new_hscroll cannot
> exceed PTRDIFF_MAX (the above code guarantees
> this directly), so their values therefore always fit
> in ptrdiff_t range even when EMACS_INT is wider than
> ptrdiff_t.

Yes, but why do that in the first place?  The value of 'hscroll' comes
from Lisp, so it's in the range of an EMACS_INT.  Why not treat it as
such?

For that matter, why not change 'hscroll' in 'struct window' to
EMACS_INT as well?

Re: ptrdiff_t misuse [was :Re: (empty)]

[Paul Eggert]

On 07/05/2012 11:43 PM, Eli Zaretskii wrote:
> The value of 'hscroll' comes from Lisp,
> so it's in the range of an EMACS_INT.
> Why not treat it as such?
> 
> For that matter, why not change 'hscroll' in 'struct window' to
> EMACS_INT as well?

I would prefer that, yes.  Although Stefan said last week that
hscroll should be 'int'
<http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00603.html>
on the grounds that hscroll values greater than INT_MAX don't work
anyway, perhaps that's moot now that you've fixed those problems with
large hscroll values.

If we change hscroll to EMACS_INT, we should also increase the max
hscroll value to MOST_POSITIVE_FIXNUM.

Re: ptrdiff_t misuse

[Eli Zaretskii]

> Date: Fri, 06 Jul 2012 00:32:06 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On 07/05/2012 11:43 PM, Eli Zaretskii wrote:
> > The value of 'hscroll' comes from Lisp,
> > so it's in the range of an EMACS_INT.
> > Why not treat it as such?
> > 
> > For that matter, why not change 'hscroll' in 'struct window' to
> > EMACS_INT as well?
> 
> I would prefer that, yes.  Although Stefan said last week that
> hscroll should be 'int'
> <http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00603.html>
> on the grounds that hscroll values greater than INT_MAX don't work
> anyway, perhaps that's moot now that you've fixed those problems with
> large hscroll values.

Stefan, do you object to making hscroll (and other values that come
from Lisp) EMACS_INT?

I think doing so will naturally and easily avoid the messy tests
against max values of several data types where we want to clip values
to some reasonable range.  So I think it will be a net win in code
clarity and maintainability, and will prevent subtle bugs.

> If we change hscroll to EMACS_INT, we should also increase the max
> hscroll value to MOST_POSITIVE_FIXNUM.

It's already that:

     ptrdiff_t hscroll_max = min (MOST_POSITIVE_FIXNUM, PTRDIFF_MAX);
     ptrdiff_t new_hscroll = clip_to_bounds (0, hscroll, hscroll_max);

(Of course, if we declare these variables EMACS_INT, PTRDIFF_MAX will
not be needed anymore.)

Or did you mean something else?

Re: ptrdiff_t misuse

[Eli Zaretskii]

> Date: Fri, 06 Jul 2012 00:32:06 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > For that matter, why not change 'hscroll' in 'struct window' to
> > EMACS_INT as well?
> 
> I would prefer that, yes.

OK, thanks.

My next issue with ptrdiff_t use is with variables that store buffer
or string positions.  They were lately converted from EMACS_INT to
ptrdiff_t.  Here're 2 examples:

  struct buffer_text
    {
      ...
      ptrdiff_t gpt;		/* Char pos of gap in buffer.  */
      ptrdiff_t z;		/* Char pos of end of buffer.  */
      ptrdiff_t gpt_byte;		/* Byte pos of gap in buffer.  */
      ptrdiff_t z_byte;		/* Byte pos of end of buffer.  */

  struct buffer
    {
      ...
      /* Char position of point in buffer.  */
      ptrdiff_t pt;

      /* Byte position of point in buffer.  */
      ptrdiff_t pt_byte;

      /* Char position of beginning of accessible range.  */
      ptrdiff_t begv;

      /* Byte position of beginning of accessible range.  */
      ptrdiff_t begv_byte;

      /* Char position of end of accessible range.  */
      ptrdiff_t zv;

      /* Byte position of end of accessible range.  */
      ptrdiff_t zv_byte;

I understand that this is done because these variables are indices
into arrays, and thus cannot hold values that the ptrdiff_t type
cannot express.  Therefore, EMACS_INT is not good here, because it can
be wider than ptrdiff_t.

If this is indeed the reason, I suggest a new typedef:

  typedef ptrdiff_t EMACS_POS;

to be used with all such variables.  I think this will contribute to
clarity of the code, since ptrdiff_t is a rarely-used type, and thus I
expect many programmers to be unfamiliar with it.  By contrast,
EMACS_POS by its very name tells what the variable can and cannot
hold.

Comments?

Re: ptrdiff_t misuse

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > My next issue with ptrdiff_t use is with variables that store buffer
 > or string positions.  They were lately converted from EMACS_INT to
 > ptrdiff_t.  Here're 2 examples:

 > I understand that this is done because these variables are indices
 > into arrays, and thus cannot hold values that the ptrdiff_t type
 > cannot express.  Therefore, EMACS_INT is not good here, because it can
 > be wider than ptrdiff_t.
 > 
 > If this is indeed the reason, I suggest a new typedef:
 > 
 >   typedef ptrdiff_t EMACS_POS;
 > 
 > to be used with all such variables.  I think this will contribute to
 > clarity of the code,

FWIW, as an occasional reader of Emacs code, I disagree.  AIUI,
EMACS_INT exists in principle to express the idea of "C implementation
of the integer type used to implement Lisp objects" (which for some
strange reason ISO/IEC JTC1/SC22/WG14 hasn't standardized, we really
should get them to fix that! ;-), and in practice because of the
horribly inconsistent treatment of integer types across platforms, and
the fact that often Emacs will prefer a wider type to a more efficient
one (in the compiler implementer's opinion).

OTOH, ptrdiff_t expresses exactly the type required by the hardware.
I don't see how you can get more clear than that.

 > since ptrdiff_t is a rarely-used type,

EMACS_INT of course is even more rarely-used. ;-)

 > and thus I expect many programmers to be unfamiliar with it.

So teach them, just as you have to teach them EMACS_INT.  The type
name is mnemonic, as are the variables it describes.  Google brings up
plenty of relevant references.  I don't see a problem.

 > By contrast, EMACS_POS by its very name tells what the variable can
 > and cannot hold.

FWIW, to me it doesn't.  It tells me what role it plays in Emacs, it
doesn't tell me anything about the actual type, or why it needs to be
different from EMACS_INT.  I think it will be very easy for people to
confound EMACS_INT with EMACS_POS, even if they're read the typedef,
because in Lisp both kinds of value are represented by the same type.
OTOH, once a hacker learns the rationale for ptrdiff_t, I think it
will be difficult to forget.

The real problem is that lazy programmers will frequently use a
generic type (such as "int") for variables, because they can't
remember the right type.  To me, "EMACS_POS" is only marginally more
memorable than "ptrdiff_t" for this purpose, and that is more than
outweighed by the precision of "ptrdiff_t" for expressing a hardware-
dependent type.

Re: ptrdiff_t misuse

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Fri, 06 Jul 2012 19:19:57 +0900
> Cc: Paul Eggert <eggert@cs.ucla.edu>, dmantipov@yandex.ru,
> 	monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> ptrdiff_t expresses exactly the type required by the hardware.

For pointer arithmetics, yes.  Which is not what we normally do with
buffer and string positions: we use them as normal integral types.

Compare that with typical declarations of array indices in C programs:
you'll rarely if ever see them declared as ptrdiff_t.

>  > since ptrdiff_t is a rarely-used type,
> 
> EMACS_INT of course is even more rarely-used. ;-)

Not for someone who hacks Emacs sources.  It's like Lisp_Object: you
get used to it very quickly and use it naturally after that.

>  > and thus I expect many programmers to be unfamiliar with it.
> 
> So teach them, just as you have to teach them EMACS_INT.  The type
> name is mnemonic, as are the variables it describes.

The type name actively resists that.  The "ptr" part is one problem,
the "diff" part is another.  None of them is related to the typical
usage of the positional values.

> [EMACS_POS] doesn't tell me anything about the actual type, or why
> it needs to be different from EMACS_INT.

Why would you care?  I don't expect J.R. Hacker to care about that,
except if she is a type junkie, in which case she just has to M-. on
the type name and see the guts.  Otherwise, all she needs to remember
is that it's "the type used for Emacs buffer/string positions".

> I think it will be very easy for people to
> confound EMACS_INT with EMACS_POS, even if they're read the typedef,
> because in Lisp both kinds of value are represented by the same type.

It is easy enough to explain that EMACS_POS is used for Lisp integers
that express buffer and string positions, and EMACS_INT for any other
Lisp integer values.

> The real problem is that lazy programmers will frequently use a
> generic type (such as "int") for variables, because they can't
> remember the right type.

I expect them to see the common practice in Emacs sources and follow
suit.  If not, they will get comments on their code to that effect and
learn fast enough.

> To me, "EMACS_POS" is only marginally more memorable than
> "ptrdiff_t" for this purpose

I didn't have you (or myself) in mind when I suggested EMACS_POS ;-)
I worry about newcomers, and would like to make their learning curve
in the matter to be as un-steep as possible.

Re: ptrdiff_t misuse

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Not for someone who hacks Emacs sources.  [EMACS_INT is] like
 > Lisp_Object: you get used to it very quickly and use it naturally
 > after that.

Well, it isn't "like" Lisp_Object; it *is* Lisp_Object!  How natural
is *that*?

 > The type name actively resists that.  The "ptr" part is one problem,
 > the "diff" part is another.  None of them is related to the typical
 > usage of the positional values.

Huh?  The only way I can understand that is that people who have no
clue about programming in C are programming in C!  Don't you find that
scary?

 > I expect them to see the common practice [using EMACS_POS] in Emacs
 > sources and follow suit.  If not, they will get comments on their
 > code to that effect and learn fast enough.

Ditto ptrdiff_t.

 > I didn't have you (or myself) in mind when I suggested EMACS_POS ;-)
 > I worry about newcomers, and would like to make their learning curve
 > in the matter to be as un-steep as possible.

I worry about newcomers, and I would prefer (if I'm going to be
reviewing) that they have a clue about programming in C if they're
going to be programming in C.  C, unlike Lisp, is the antithesis of a
"safe" language.  *Especially* when using pointers (which, in case
you've forgotten ;-) is what C arrays -- including Emacs buffer and
string data -- are!

But I'm not going to be reviewing, most likely.  I just wanted to
point out that there is a school of thought opposed to yours.

Re: ptrdiff_t misuse

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: eggert@cs.ucla.edu,
>     dmantipov@yandex.ru,
>     monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Fri, 06 Jul 2012 21:02:32 +0900
> 
> Eli Zaretskii writes:
> 
>  > Not for someone who hacks Emacs sources.  [EMACS_INT is] like
>  > Lisp_Object: you get used to it very quickly and use it naturally
>  > after that.
> 
> Well, it isn't "like" Lisp_Object; it *is* Lisp_Object!

Yes, as long as you don't use USE_LISP_UNION_TYPE (or
CHECK_LISP_OBJECT_TYPE in the current development sources), in which
case it's not.

>  > The type name actively resists that.  The "ptr" part is one problem,
>  > the "diff" part is another.  None of them is related to the typical
>  > usage of the positional values.
> 
> Huh?  The only way I can understand that is that people who have no
> clue about programming in C are programming in C!

"No clue" is an exaggeration, IMO.  One can program in C without
remembering by heart all of its obscure data types.  Latest standards
add more and more of them.

> But I'm not going to be reviewing, most likely.  I just wanted to
> point out that there is a school of thought opposed to yours.

I have no doubt that it exists, just look at the Emacs sources
lately ;-)

Re: ptrdiff_t misuse

[Paul Eggert]

On 07/06/2012 01:34 AM, Eli Zaretskii wrote:
>> If we change hscroll to EMACS_INT, we should also increase the max
>> > hscroll value to MOST_POSITIVE_FIXNUM.
> It's already that:
> 
>      ptrdiff_t hscroll_max = min (MOST_POSITIVE_FIXNUM, PTRDIFF_MAX);
>      ptrdiff_t new_hscroll = clip_to_bounds (0, hscroll, hscroll_max);
> 
> (Of course, if we declare these variables EMACS_INT, PTRDIFF_MAX will
> not be needed anymore.)
> 
> Or did you mean something else?

No, that's pretty much what I meant -- get rid of the PTRDIFF_MAX there
while we're changing ptrdiff_t to EMACS_INT for hscroll values.  Some
other minor things would need changing too, but it shouldn't be a
problem.

Re: ptrdiff_t misuse

[Paul Eggert]

On 07/06/2012 04:01 AM, Eli Zaretskii wrote:
> It is easy enough to explain that EMACS_POS is used for Lisp integers
> that express buffer and string positions, and EMACS_INT for any other
> Lisp integer values.

But not every use of ptrdiff_t is for buffer and string positions.
Bitmap table sizes, for example.  So we would need three types:

  EMACS_INT for Lisp integer values
  EMACS_POS for buffer and string positions
  ptrdiff_t for other large memory-related numbers

and at that point, we'll need to teach Emacs hackers about
ptrdiff_t anyway.

An argument for EMACS_POS is that it clearly identifies an
integer as being used for a buffer or a string position, as
having some other ptrdiff_t-like use.  But in that case shouldn't
we also distinguish between buffer positions and string positions?
And distinguish between character and byte counts, in both cases?
Something like this?

  EMACS_INT for Lisp integer values
  EMACS_BUFCPOS for buffer char positions
  EMACS_BUFBPOS for buffer byte positions
  EMACS_STRCPOS for string char positions
  EMACS_STRBPOS for string byte positions
  ptrdiff_t for other large memory-related numbers

This question answers itself, I think -- the extra complexity
isn't worth it, and we should stick with EMACS_INT and ptrdiff_t.

I think most competent C programmers know ptrdiff_t well enough.
They think of it being like size_t, but signed.  Other GNU software
tends to prefer size_t, but the Emacs style is to prefer signed
integers and ptrdiff_t is the obvious alternative.  I agree 
that most C programs use 'int' for indexes, but that's because
they're small indexes.  Emacs does this too, when indexes are
known to be sufficiently small.

Re: ptrdiff_t misuse

[Eli Zaretskii]

> Date: Fri, 06 Jul 2012 07:56:48 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: "Stephen J. Turnbull" <stephen@xemacs.org>, dmantipov@yandex.ru, 
>  monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> On 07/06/2012 04:01 AM, Eli Zaretskii wrote:
> > It is easy enough to explain that EMACS_POS is used for Lisp integers
> > that express buffer and string positions, and EMACS_INT for any other
> > Lisp integer values.
> 
> But not every use of ptrdiff_t is for buffer and string positions.
> Bitmap table sizes, for example.

Do they really need to be large?

>   EMACS_INT for Lisp integer values
>   EMACS_POS for buffer and string positions
>   ptrdiff_t for other large memory-related numbers
> 
> and at that point, we'll need to teach Emacs hackers about
> ptrdiff_t anyway.

Not if the objects that use ptrdiff_t are many.  And perhaps we don't
need ptrdiff_t at all, if the size doesn't need to be large.

> An argument for EMACS_POS is that it clearly identifies an
> integer as being used for a buffer or a string position, as
> having some other ptrdiff_t-like use.  But in that case shouldn't
> we also distinguish between buffer positions and string positions?

What for? they span the same range of values.

> And distinguish between character and byte counts, in both cases?

What for? they span the same range of values.  And the fact that it's
a byte position is usually clearly stated in the name of the variable
itself.

>   EMACS_INT for Lisp integer values
>   EMACS_BUFCPOS for buffer char positions
>   EMACS_BUFBPOS for buffer byte positions
>   EMACS_STRCPOS for string char positions
>   EMACS_STRBPOS for string byte positions
>   ptrdiff_t for other large memory-related numbers
> 
> This question answers itself, I think -- the extra complexity
> isn't worth it

Only if you take the argument towards the absurd.

Re: ptrdiff_t misuse

[Paul Eggert]

On 07/06/2012 08:43 AM, Eli Zaretskii wrote:
>> But not every use of ptrdiff_t is for buffer and string positions.
>> > Bitmap table sizes, for example.
> Do they really need to be large?

In some cases yes -- certainly in the memory allocators.
Maybe in some cases not, but nobody has taken the time
to think about it, and in the meantime ptrdiff_t is safer.
Generally speaking, if an object can grow and its size
is not limited for other reasons to INT_MAX-or-less,
code should not use 'int' to count its size.

> What for? they span the same range of values.

Yes, that's the point -- if ptrdiff_t and EMACS_POS
would span the same range of values, why bother to
distinguish the two?  Whether a value is a
buffer position is usually clearly stated in the
variable name.

Re: ptrdiff_t misuse

[Eli Zaretskii]

> Date: Fri, 06 Jul 2012 08:56:04 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: stephen@xemacs.org, dmantipov@yandex.ru, monnier@iro.umontreal.ca, 
>  emacs-devel@gnu.org
> 
> > What for? they span the same range of values.
> 
> Yes, that's the point -- if ptrdiff_t and EMACS_POS
> would span the same range of values, why bother to
> distinguish the two?

Because Emacs positions are not pointers, nor differences between
pointers.

> Whether a value is a buffer position is usually clearly stated in
> the variable name.

I refer you to the recent repeated confusions about this by Dmitry.

Re: ptrdiff_t misuse

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 > > Huh?  The only way I can understand that is that people who have no
 > > clue about programming in C are programming in C!
 > 
 > "No clue" is an exaggeration, IMO.  One can program in C without
 > remembering by heart all of its obscure data types.

The name "ptrdiff_t" may be obscure, but the type ptrdiff_t hardly is.
It's at the heart of C programming.  I can't imagine anybody will have
trouble remembering what it means once they learn it.

Re: ptrdiff_t misuse

[Dmitry Antipov]

On 07/06/2012 08:00 PM, Eli Zaretskii wrote:

>> Yes, that's the point -- if ptrdiff_t and EMACS_POS
>> would span the same range of values, why bother to
>> distinguish the two?
>
> Because Emacs positions are not pointers, nor differences between
> pointers.

IMHO you mix the confusing type name and it's real use.

I read ptrdiff_t exactly as "difference between pointers", and this is
the minor drawback; the major one is that there is no standard unsigned
counterpart, like for size_t/ssize_t pair.

>> Whether a value is a buffer position is usually clearly stated in
>> the variable name.
>
> I refer you to the recent repeated confusions about this by Dmitry.

This isn't related to any type (mis)use. In a struct window,
window_end_pos really means something like last_displayed_pos;
this is quite hard to mix with window_end_[whatever].

Dmitry

Re: ptrdiff_t misuse

[Paul Eggert]

On 07/06/2012 09:42 AM, Dmitry Antipov wrote:
> I read ptrdiff_t exactly as "difference between pointers", and this is
> the minor drawback; the major one is that there is no standard unsigned
> counterpart, like for size_t/ssize_t pair.

For buffer positions and the like, Emacs code can take size_t to be
the unsigned counterpart of ptrdiff_t.  For Emacs we typically prefer
signed integers, so the need for size_t is rare -- in fact some of the
current uses of size_t should be changed to ptrdiff_t, for consistency
with the usual Emacs style.

There are hosts with size_t wider than ssize_t (POSIX allows this).
That is why we use ptrdiff_t, not ssize_t, for buffer positions and
the like -- on those hosts, ssize_t wouldn't work for large buffers.
Conversely, on some (rare) hosts ptrdiff_t is wider than size_t (POSIX
allows this too).  As far as I know Emacs has never been ported to
these hosts but it should work, since buffer positions will fit into
ptrdiff_t.

Re: ptrdiff_t misuse

[Stefan Monnier]

> Stefan, do you object to making hscroll (and other values that come
> from Lisp) EMACS_INT?

Yes.  A large value makes no sense.  It should be int.
And I'm perfectly happy with taking very-large values and letting them
wraparound.  Those values are bogus anyway.


        Stefan

Re: ptrdiff_t misuse

[Samuel Bronson]

On Jul 6, 2012, at 5:30 PM, Stefan Monnier wrote:

>> Stefan, do you object to making hscroll (and other values that come
>> from Lisp) EMACS_INT?
>
> Yes.  A large value makes no sense.  It should be int.
> And I'm perfectly happy with taking very-large values and letting them
> wraparound.  Those values are bogus anyway.

... but isn't that Undefined Behavior?

Re: ptrdiff_t misuse

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> If this is indeed the reason, I suggest a new typedef:
>
>   typedef ptrdiff_t EMACS_POS;
>
> to be used with all such variables.  I think this will contribute to
> clarity of the code, since ptrdiff_t is a rarely-used type, and thus I
> expect many programmers to be unfamiliar with it.  By contrast,
> EMACS_POS by its very name tells what the variable can and cannot
> hold.

This is a bad idea.  Since EMACS_POS would occur rarely in the code, it
would be necessary to look up what it means when you stumble across it.
It would be easier to simply remember the meaning and use of ptrdiff_t.
Introducing yet another type defeats the purpose.

Re: ptrdiff_t misuse

[Stefan Monnier]

>>> Stefan, do you object to making hscroll (and other values that come
>>> from Lisp) EMACS_INT?
>> Yes.  A large value makes no sense.  It should be int.
>> And I'm perfectly happy with taking very-large values and letting them
>> wraparound.  Those values are bogus anyway.
> ... but isn't that Undefined Behavior?

In the context of Emacs I'm not scared of undefined behavior.


        Stefan

Re: ptrdiff_t misuse

[Paul Eggert]

On 07/07/2012 03:59 AM, Stefan Monnier wrote:
> In the context of Emacs I'm not scared of undefined behavior.

Emacs uses undefined behavior all the time, and there's
nothing wrong with that.  But it has to be careful about
which undefined behavior it can rely on.  In the old days,
it was fine for Emacs to assume that signed integer overflow
wraps around.  But because compilers have gotten much fancier
at optimizing, the corresponding undefined behavior no longer
results in simple wraparound, but can lead to subtle logic
bugs far away from the offending code.

Over the past couple of years we've changed Emacs so that it
is now fairly good at avoiding signed integer overflow.
One can build it with gcc -ftrapv and it doesn't trap, for example.
This kind of analysis and testing helps to make Emacs more reliable.
When it doesn't significantly impede more-important concerns
it should be encouraged, even if it isn't the highest-priority task.

(unknown)

[João Távora]

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

Hi,

I'm a gnus newbie and using it for about two weeks in just one of my IMAP
mail accounts. I like it so far, but wonder at its marking system...

To the question: Does it make sense to not use gnus-ancient-mark "O"
completely? I want to see old marks that I laboriously set in previous
sessions, such as the gnus-del-mark "r" mark. It seems to be replaced by
"O" all the time.

If so how would I achieve this?

-- 
João Távora

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

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> To the question: Does it make sense to not use gnus-ancient-mark "O"
> completely? I want to see old marks that I laboriously set in previous
> sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> by "O" all the time. 

"r" just marks stuff as read, and this isn't saved beyond that.  Any way
of marking stuff as read ends up in the same data set, so it's all
displayed as "O".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: (unknown)

[João Távora]

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

I see, so the difference between "r" and "R" is just for the current
"summary mode" session.

Curious, when does adaptive scoring kick in then? It does differentiate
between "r" and "R" doesn't it?

Thanks (and sorry for not including a subject, I stupidly forgot)
João

On Sat, Jul 6, 2013 at 4:22 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > To the question: Does it make sense to not use gnus-ancient-mark "O"
> > completely? I want to see old marks that I laboriously set in previous
> > sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> > by "O" all the time.
>
> "r" just marks stuff as read, and this isn't saved beyond that.  Any way
> of marking stuff as read ends up in the same data set, so it's all
> displayed as "O".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog http://lars.ingebrigtsen.no/
>



-- 
João Távora

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

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> I see, so the difference between "r" and "R" is just for the current
> "summary mode" session.

Yes.

> Curious, when does adaptive scoring kick in then? It does
> differentiate between "r" and "R" doesn't it?

Adaptive scoring kicks in as you're leaving the summary buffer, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

(unknown)

[Eli Zaretskii]

Bootstrapping master from the git repo, I see multiple error messages
like this:

  Eager macro-expansion failure: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

Does anyone else see this?

Re: (unknown)

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Bootstrapping master from the git repo, I see multiple error messages
> like this:
>
>   Eager macro-expansion failure: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>
> Does anyone else see this?

Yes, I get the same thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

(unknown)

[David Kastrup]

Unless objected to timely, I intend to push this change tomorrow.  It
should not affect current operation but brings Emacs' behavior for
synthesized Lisp events containing an "up-" modifier in line with the
current behavior of "down-" events.  Such events are not produced by
Emacs itself; no change in behavior for existing code is expected.

I have code that might eventually make it into ELPA that benefits from
these changes.

Re: (unknown)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Unless objected to timely, I intend to push this change tomorrow.  It
> should not affect current operation but brings Emacs' behavior for
> synthesized Lisp events containing an "up-" modifier in line with the
> current behavior of "down-" events.  Such events are not produced by
> Emacs itself; no change in behavior for existing code is expected.
>
> I have code that might eventually make it into ELPA that benefits from
> these changes.

Ugh.  Sorry for the Subject line.  This concerns the patch in the
message with title:

[PATCH] Deal gracefully with up-events (Bug#19746)

-- 
David Kastrup

(unknown)

[steve]

From: Steve Purcell <steve@sanityinc.com>
Date: Mon, 8 Feb 2016 20:47:43 +1300
Subject: [PATCH] Safer prompt-regexp for postgres/vertica in
 sql-interactive-mode
--text follows this line--

Fixes issue 22596, whereby "_" is now not considered a word constituent
character in sql-interactive-mode, so prompts like "foo_dev# " are not
correctly detected.
---
 lisp/progmodes/sql.el | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/sql.el b/lisp/progmodes/sql.el
index fd59f46..90c8dfe 100644
--- a/lisp/progmodes/sql.el
+++ b/lisp/progmodes/sql.el
@@ -462,9 +462,9 @@ sql-product-alist
      :list-all ("\\d+" . "\\dS+")
      :list-table ("\\d+ %s" . "\\dS+ %s")
      :completion-object sql-postgres-completion-object
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] "
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] "
      :input-filter sql-remove-tabs-filter
      :terminator ("\\(^\\s-*\\\\g$\\|;\\)" . "\\g"))
 
@@ -514,9 +514,9 @@ sql-product-alist
      :sqli-comint-func sql-comint-vertica
      :list-all ("\\d" . "\\dS")
      :list-table "\\d %s"
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] ")
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] ")
     )
   "An alist of product specific configuration settings.
 
-- 
2.7.1

Re: (unknown)

[Steve Purcell]

Sorry, messed up sending that patch by email, but it's hopefully helpful
nonetheless.

-Steve

(unknown)

[Anders Lindgren]

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

Hi!

About a year ago, the long time maintainer of the official Emacs user
interface on OS X (the "nextstep" or "NS" user interface), retired from
Emacs. This is very unfortunately, as he did a very, very good job for
during the years he was active.

When I found out about this, about six months ago, I stepped up as I had
some knowledge after having worked along side of him on some NS-related
features.

Unfortunately, my personal situation has since changed so I no longer can
handle the NS user interface by myself.

In other words, I'm looking for someone or a group of people who are
interested in enhancing Emacs on OS X, or at least making sure that it
doesn't stop working.

To make it easier to start working on the NS port, I've updated the README
and add a WISHLIST of features that I would like to see implemented.

I will still be around, but I find that time no longer permits me doing
much core development work.

Sincerely,
    Anders Lindgren

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

(unknown)

[Takesi Ayanokoji]

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

Hi developers.

I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.

  Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
  Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs

So, how should I take next action.
Submit it to somewhere, or else?
(Currently I am sharing it by GitHub.)

Any ideas?

Thanks.

---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

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

Re: (unknown)

[Byung-Hee HWANG (황병희, 黃炳熙)]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> 께서 쓰시길,
 《記事 全文
 <CAN7WbibOXQGSCYbzErB9e9X3YinM3OmBinApAM15hecx4O7-PA@mail.gmail.com>
 에서》:

> Hi developers.
>
> I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.
>
>   Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
>   Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs
>
> So, how should I take next action.
> Submit it to somewhere, or else?
> (Currently I am sharing it by GitHub.)
>
> Any ideas?
>
> Thanks.

Takesi-san, it is very hard work, i think. You are strong man. Anyway
thanks thanks thanks!!!

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

(unknown)

[Chris Gregory]

Here is another patch that does more of this.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..9e1d612 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1313,20 +1313,12 @@ internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
 			 Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun ();
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun ();
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with ARG as its argument.  */
@@ -1364,20 +1356,12 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg1, arg2);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg1, arg2);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with NARGS as first,
@@ -1393,20 +1377,12 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
 						Lisp_Object *args))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val, nargs, args);
-    }
-  else
-    {
-      Lisp_Object val = bfun (nargs, args);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (nargs, args);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val, nargs, args) : val;
 }
 
 struct handler *

Re: (unknown)

[Andreas Schwab]

On Dez 28 2016, Chris Gregory <czipperz@gmail.com> wrote:

> Here is another patch that does more of this.

Nothing of that is valid C.

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."

(unknown)

[Paul Pogonyshev]

>>> Have you tried to measure the impact of your patch on the actual problem?
>> I mentioned 3%.
>
>That's the percentage impact on the number of lambdas.  I'm curious
>about its impact on actual problematic aspects, such as speed and code
>size (and compilation time, I guess).
>
>> Yes, it is practically negligible, but this is a first small patch and
>> I'm willing to work on improving generators further.
>
>Of course.

Actually, forget it. It's too complicated to jump through all the hoops here.

I would just be glad if someone applied the patch from bug 26068. It's a
fix, not an optimization, and there is example of a form, evaluation of
which it fixes.

And if you reply, *please*, keep me on CC, otherwise I won't see your
mail.

Paul

Re: (unknown)

[Mark Oteiza]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

>>>> Have you tried to measure the impact of your patch on the actual problem?
>>> I mentioned 3%.
>>
>>That's the percentage impact on the number of lambdas.  I'm curious
>>about its impact on actual problematic aspects, such as speed and code
>>size (and compilation time, I guess).
>>
>>> Yes, it is practically negligible, but this is a first small patch and
>>> I'm willing to work on improving generators further.
>>
>>Of course.
>
> Actually, forget it. It's too complicated to jump through all the hoops here.

Darn.  Such improvements would be nice.

> I would just be glad if someone applied the patch from bug 26068. It's a
> fix, not an optimization, and there is example of a form, evaluation of
> which it fixes.

Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
bug#12119 which the previous code was fixing.

Re: (unknown)

[Paul Pogonyshev]

>> I would just be glad if someone applied the patch from bug 26068. It's a
>> fix, not an optimization, and there is example of a form, evaluation of
>> which it fixes.
>
> Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
> bug#12119 which the previous code was fixing.

Thank you. If you are familiar with the code involved, can you please also
look at bug 26073? It's related, but more difficult to fix. I added a patch to
the bug report, but I don't think the patch is ready for application. Maybe
someone could finish it.

Paul

(unknown)

[Mark Oteiza]

Hi,

I wrote the following to get rid of the 'apply' here.  The
expansion is something that, according to how byte-switch is described,
should compile to a switch/jumptable, but it isn't happening.

Applying the following, doing M-x byte-compile-file, and inspecting the
.elc/disassembly I am seeing a series of goto-if-nil.  Am I doing
something wrong?

diff --git a/lisp/json.el b/lisp/json.el
index 64486258cc..6990ddd0f5 100644
--- a/lisp/json.el
+++ b/lisp/json.el
@@ -683,6 +683,23 @@ json-readtable
     table)
   "Readtable for JSON reader.")
 
+(defmacro json-readtable-dispatch (char)
+  "Dispatch reader function for CHAR."
+  (declare (debug (symbolp)))
+  (let ((table
+         '((?t json-read-keyword "true")
+           (?f json-read-keyword "false")
+           (?n json-read-keyword "null")
+           (?{ json-read-object)
+           (?\[ json-read-array)
+           (?\" json-read-string)))
+        res)
+    (dolist (c '(?- ?+ ?. ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9))
+      (push (list c 'json-read-number) table))
+    (pcase-dolist (`(,c . ,rest) table)
+      (push `((= ,char ,c) (,@rest)) res))
+    `(cond ,@res (t (signal 'json-readtable-error ,char)))))
+
 (defun json-read ()
   "Parse and return the JSON object following point.
 Advances point just past JSON object."
@@ -690,10 +707,7 @@ json-read
   (let ((char (json-peek)))
     (if (zerop char)
         (signal 'json-end-of-file nil)
-      (let ((record (cdr (assq char json-readtable))))
-        (if (functionp (car record))
-            (apply (car record) (cdr record))
-          (signal 'json-readtable-error record))))))
+      (json-readtable-dispatch char))))
 
 ;; Syntactic sugar for the reader
 

(unknown)

[siraben]

I'm new to contributing, so I was wondering if this is a viable
project to get started on.

I've noticed that development on the Emacs Calc has stalled
recently. /lisp/calc shows no commits since January 1 2018, which was
a copyright year update. I would like to contribute documentation to
many of the undocumented functions, and work on the symbolic
integration algorithm which, despite its complexity, still has great
difficulty with integration by parts and by substitution.

What are some recommended starting points for first-time contributors?

Thanks,

Ben Phipathananunth

(unknown)

[Ag Ibragimov]

Spacemacs (community-driven Emacs distribution/config) has a feature called Layers, Doom-Emacs (another community-driven Emacs config) has a similar feature (I think they are called Modules).

A Layer is a bundle of [related] Emacs packages that work together and very often tightly integrate (with one another) to provide a comprehensive set of features to achieve specific goals. For example, there are many language-specific Spacemacs layers: Python, Lua, Haskell, etc.
For example, the Python layer includes basic Python-related packages and sets defaults for Flycheck, Company, etc.
There also layers for tools like Docker or layers for version-control, et al.

So my question is: Has anyone ever thought about designing a sort of standardized module system? It would be great if we could have a unified model for creating such bundles.
Wouldn't be nice if for example, instead of discovering, installing and configuring a bunch of related packages, an Emacs user would say: "install LaTeX module" and then "customize "LaTeX module", etc.

Emacs ecosystem is growing. There are hundreds (maybe more) packages; standardizing a system that would allow the "plug-n-play" experience would be very nice. Otherwise, everyone would continue solving same problems in their own, unique ways, increasing entropy towards the "Lisp curse."

(unknown)

[Troy Hinckley]

Subject: Load order for elisp files
User-agent: mu4e 1.2.0; emacs 28.0.50

I am trying to better understand the bootstrap process for Emacs and I
have run into a chicken and egg problem. When looking for where the
basic functions are defined, I can see that defmacro and defun are defined in
byte-run.el. However the code needed to evaluate a macro is in
backquote.el. But backquote.el uses defun, which is defined in
byte-run.el. Which of these files is loaded first, and how does Emacs
work around this apparent causality dilemma?

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:35:54 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <20210819024728.kgnf6jmpakqdto4p@Ergus>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:35:51 +0200
Message-ID: <87k0kcovp4.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:sxHfD7zdrmCrHJSZln2GfPWmdbMMIDsRDQsLpU/nfq2YcMnLSwp
 hYDoOFW4h00C5RkEQiWqTD0Ghszr1rlMksOFjeCzf6UdQ6KCjGfM9H/0FNpGLz//8NEoqgM
 S5utAAvPbhusMs8u3C+lcawvEbL65zJofM+Ydv0o9vvHaRqEnoH26xvM2TKzTcYI3D+cvMJ
 tbufjgNLdJD0dp/gT0Usg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:0O6w3nRKzCM=:0yGavBBfSnyh5UA4ZyLNTu
 xZveGSXWYdvpP90089lYIVteVaqX2TjAGj5I0C+mVPtjbh++j7XzPszGW59UNb8XhbXv/RRAU
 PaKuQZQs2zeJi6m/mnUR28wuFqa9EJFXsUMLywX7A9pcq+nj88RJDkFOyOUucK8ZRDJczVJtq
 hCRthc8vZLS9I7t/BScUxTX0Gkr572eqLRSK7ZAnzyi28WyMc4Q67ujkJYogQakM7BESX2mqb
 n+cqLaM/SkXB4ftaF7C8YmAY7GFK64ACinZ71HIBSIVZhIDaFwmTiO3KSz0zuGFf9pYBndhTr
 iuv3dGLvRCBxYAxZ/8PDf2xts3TXZK6WpjTyQVjthqj5y9OwIYt2kZrgnV0PrbFfAm1H6RPcT
 xQqoU1Xhi3xaLOnNKx5DQp+M3P5/x1uu24XDKzXlVaAmN3r8tMcfbLFbE8Rk5+ikVt5xVHvXM
 pZHJA5ggu0HowH10nfZZ4b9dmeCitsqF9dVOA/sv9WsRdQ+M33ZsdYpk5UTaurTjfVU6JWaOG
 gScUUAQx9O2Iltx9m/jOlfw9aOZQ4cv9uNRiJc0ujo0Iv3T2oqkKoBjTVj5WUY2mqfPkKIhLe
 PqiVdMC2viIT1LzxgCRzghRqizF0E6OGu1twlQNqBMxo8J1MbU5OYo/uJ/QoF4DMY7Z7TgVyc
 4X3WbN7qsken+icUxr5UljsAhpg3Y9VdcF1aLJuFObC5ceIlMAylmUt0MzVfdhDGf4fy7lMWD
 3WVTDeehE5N+vf+gtoktTNzUUVujv6vDihkwb8M8cWBC0iDlLFf7a74EyzY+B4Hgc3Lc4HXGz
 C1HnGSPrG5xCYjzjGRaEulxTMjIBoCaBjj7UamceG6e+8preYjhjJlboGUEc2jWUAhUlK1E/I
 U92uRwgIm+mLukfNLQO/jzObm/a6Xd8xI8DXV3NGzqLWBNR5zZrhXErR2CM9bYihuPyN6Mw+t
 +v9efj6W3mrNpQEjsquqT7OrC3PVSRX8ZER0SkyOmvje3HyALBssD5NBvtOl1YBiYAFN2IbdH
 f2lclpuTkYQ73x9fe5OxwVoz71ASxro8z+oG1pRYVnwfWLwbNw+UK2n9qWxEblnARL9lfLqAr
 LRIc8W9CUi1Q6qGkLmdnpUYMF9eR2jPfzzqbhwIyj7rdZtkfYFCveiAPQ==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
> I don't actually know about any keyboard with a print
> button...

wouldn't that be the PrtSc key which is on every standard PC
keyboard right of F12 and above of Insert?

> But I suppose there should be some. If someone has it;
> please could you check with xev and cat+xterm what it
> sends?

Said key gives via cat on xterm:

^[[2~

and xev says the same.

Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:37:01 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <87k0kcovp4.fsf@no.workgroup>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus> <87k0kcovp4.fsf@no.workgroup>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:36:58 +0200
Message-ID: <87h7fgovn9.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:HRO/ZXce88Iozn+9UJq+ekk0abWiVqAiW05nvxhROUw4xLXvaVA
 I8MJYVw59QFHLg4As0OZgf1yCpriSS+YQsdNhys754yK6pB/wk2+6i/PbDMRG3YQWQXBUpo
 tvTC4EpNZXzi5CJg4d4uCg+Wj9SxoajT3JMmIXMug1Xz00P1aemSpf0v6oIf5wFAQ/lSwTr
 D/dkF2dL88+BwVa6vBhhw==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:x+ng0FuV5Xw=:c1ueAnEJSAQkxkyqjZnCx1
 KN6IxRv+LnP6G96c416OIk26JuOsdDTIyiXvEUq6QzrLXZ5rgupHYTCvwJQGBvSvaDphMyFDW
 ST49PCmrRrxwWE1dbBVQ27MMr+q1Ny0ITq7KtafxKw1tmDO6FXXA5N8RaecNs6vDmCQtpbW9z
 /HKAM7MjtdvPVAgtFnY/AYbwK+/jXHEFARP5XNgHbQOOdf9n6GiLAP55AehHp6mv7J+f1yr/Y
 ciX0YuEm8kHEixainZ80as4FOQarr0Vetdd59a+BwIafQxT2iUR+brhxxJxEBH4GR7/F7yN5G
 Ftp4iQDM45po2gmJlveQrUj25Urfz6f0reLHFwE/OfQq9wHaElOvOeZUnOsE6xnxh/PL7kASV
 mbYfUxKk1iCdDC8thJtevvbox8fw8bwCSSzcgwwN1SvtkFXGmZxk1ah64ue4Re/slO35L2voM
 fN+xxT6j8MJwtERNEhJZxeGBgQMVlQ+HuErhFhx5zq96HJgNZh6mHER4/hwHyJ7VPWJDpcMqu
 +gQD5H75FMDrPdWeti2lUxpPbqNcVvEvlziv4agxtJGYTNn75GtI526JU20W/5f1oZuwwoFre
 f+oXHczb6XnEctuTuUlJfPQkBvqDfWTk0X7KvzqmyYJyNjJOmo74O/kIIySZbfhruL3HLs7ba
 r2ofHxlQsyJvZRiJ2sX8xbA5aYVI7830NBkvi3aQeQ2PpHpI3FUg8Z0+Hcumly9COz75+GbM3
 pSje0giAF92ACLFp9kbyeRwKJpdpaZy81alSigFqMF9l6gHvY9v1EP3lHX6L1vC1w9S/bTqoQ
 yioc6IwC4iqTnPQV4agbfB7Xyy3IRD2TDh3ntAVihDXMb6IjBr6jSL3dB8hKU9JUAOiBuGy20
 DtvVNkoryKhJQFjg9N8qtjj7NdZuG+iX4bhej2GzQc6/jqOvev4umnj8n1l7AWUiSJWeT3Mec
 auVYAJHcixI79uAPvWH/7R8F2vLv+mtt/oO+3OTz1KDSntG+OiwefVZFSn6tvtfi0cA2GRH/q
 HpF7JyrC/S5FP0PaE9nXV2526YQacHrPSpmbJB5sMxwpOBQ6UYbTV0y9OqtDIkKBh9mwOJ8jL
 nkPnOo63oY9QmXA63umgtmElXMZvdLieT/clPOiVNacWQUdXuMJKa29kw==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> * Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.

on debian buster, that is.


Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[Davin Pearson]

[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]

I was wondering if you could make the following improvement to
GNU Emacs: Make it so that fonts with a nil for background-colour
have the fontification of the inner symbols shines through
to appear over higher layers, like so:

*abc* is fontified as a blue foreground with nil background

"*abc*" is fontified in light blue background with a black foreground
but should appear with a light blue background and a blue foreground.

Here is the Elisp code that I want the behaviour of which changed:

(set-face-foreground 'dmp-face--fg:blue "#000")
(set-face-background 'dmp-face--fg:blue nil)

("\\*.*\\*" 0 'dmp-face--fg:blue t)



-- 
Sorry about the delay in getting back to you.
I am only allowed my computer once per week
so that makes for a two-three week round trip in
getting back to you.

[-- Attachment #1.2: Type: text/html, Size: 1041 bytes --]

[-- Attachment #2: old-screenshot-20211212-181211.png --]
[-- Type: image/png, Size: 261635 bytes --]

[-- Attachment #3: new-screenshot-20121212-181236.png --]
[-- Type: image/png, Size: 262908 bytes --]

(unknown)

[Pedro Andres Aranda Gutierrez]

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

> Date: Sat, 28 May 2022 08:43:13 +0800
> From: Po Lu <luangruo@yahoo.com>
> To: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: ns-do-applescript
> Message-ID: <87leumebby.fsf@yahoo.com>
> Content-Type: text/plain

> Richard Stallman <rms@gnu.org> writes:

> > I have never heard of "osascript".  What is that?  What systems
> > support it?  Does it exist on GNU/Linux?

> It's only present in macOS.
Right

> > Basically, what are the differences that make it better to use
> > osascript than applescript?

> I think that binary _is_ Apple's proprietary AppleScript interpreter,
Indeed it is

> but using it in a subprocess to retrieve only contacts data (which is
> already possible on free systems) must be more acceptable than Emacs
> including a C primitive to do the same thing.

Not only that. You can do things like raising Emacs to the top and other
system actions that would otherwise require (Objective-)?C functions in the
Emacs executable.

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

(unknown)

[Gregory Heytings]

a29a3ad55d breaks the build of master with:

cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil

(unknown)

[Pedro Andres Aranda Gutierrez]

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

Rob writes:
> Regarding the writes to HOME, etc.  I think David covered that fairly
> well -- Debian runs emacs to "do things" (build .elcs, run tests, etc.)
> at package build time, package install time, and during package testing.
> In all of these cases, we're likely to want to avoid side-effects outside
> the build/test dir like writing .elc or .eln files to the current user's
> HOME, whether that's /root/ or /home/*.  It sounds like we may be able
> to accomplish that by redirecting everything to a temp dir, which is
> likely fine.

I know this may come late and be redundant, but just my .01 cents of
experience:
I have my own tweaked Debian infra to build emacs29 for Ubuntu and I have
native-compile enabled. All .eln files generated during build from the
emacs (git) source are stored in /usr/lib/emacs-xyz and are never
recompiled when I run emacs.

What actually gets natively compiled to $HOME/.emacs.d/eln-cache is any
package that I download from (m)elpa-xyz as a result of my
HOME/.emacs.d/init.el

I may be doing something wrong, but AFAIK it seems to work and I have the
same functionality on my Ubuntu natively-compiled Emacs and on the macOS
(both running +/- the same snapshot of the emacs master git branch), where
I have no native compilation.

I hope I somehow contributed something ;-)
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

(unknown)

[Pedro Andres Aranda Gutierrez]

Joao Tavora wrote:

> This indeed works, I've fixed the manual which previously said that
> setting the variable globally "doesn't make sense".  It can be useful,
> if you know what you're doing.

;-)

> But I don't know if we should be recommending this over the use of
> eglot-server-program + :initializationOptions as described in section
> 5.1 User-specific configuration.  Will see.

Fine, I don't know either whether you should _recommend_.

But, at least mentioning that this can be done to have an initial configuration
to start with... There is no one fits all and some tweaks may be needed
in some projects, but an initial config can speed up the process and it is
'as bad as' putting the dir-locals in your git repo and someone opening it
with -say- vscode or vi ;-)

/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

On Sat, 11 Mar 2023 04:45:21 -0800, Ongaro <david.ongaro@hamburg.de> wrote

> I don't understand this argument. If you're an Emacs user who uses
> tree-sitter the probability is high that you're also a developer so you
> need development tools like a compiler anyway. Especially in a
> "professional" programming environment. A sys-admin banning that would
> be an admin banning you from work.

Two things to bring another perspective:

1.- the probability is high, but what do we do with the (1-p)... shy
them away? ;-)
2.- with the current landscape, even professional developers can't
sometimes do what they need.
There is this balance between productivity and security, which I do
understand. I've already seen a couple of frighting attacks...

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Greg Minshall]

hi.  i would like to be able to write Emacs scripts ("#!...") that allow
a user to enter almost any option to the script itself, *without* having
to use double dashes ("--") to avoid colliding with Emacs option
processing.

looking at "--script" and "-x", this doesn't seem possible.

as a test case, given a simple script foo.sh (*), using "-x", and
invoking it with an option "--eval" gives this error:

----
% ./foo.sh --eval
emacs: Option '--eval' requires an argument
----

(that bare "--eval" *should* be an error if it were meant for Emacs
itself; however, it is meant for the Emacs script, which may have other
ideas of the syntax/semantics of "--eval".)

the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
"-scripteval") like a "--" on the command line, and *seems* to allow
arbitrary options on the command line.  for example, with this patch
installed:

----
% ./foo.sh --eval
command-line-args-left (--eval)
----


i wonder if this might be of use for Emacs?  if there are worries about
backwards compatibility with "-x", well ... "-y" anybody?  :)

(i was thinking of writing a test to go with the patch, but the ERT
framework is maybe a bit awkward for tests of essentially
shell-command-line functionality.  i may have missed it, but i didn't
see anything in ./test/Makefile.in that seemed to be aimed at testing
command-line invocation of Emacs.)

cheers, Greg


(*) foo.sh
----
#!/usr/bin/env -S emacs -x

(message "command-line-args-left %s" command-line-args-left)

1
----


(**) proposed patch
----
diff --git a/src/emacs.c b/src/emacs.c
index 6101ed4004c..6e140177086 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2795,9 +2795,10 @@ sort_args (int argc, char **argv)
        {
          int match;

-         /* If we have found "--", don't consider
-            any more arguments as options.  */
-         if (argv[from][1] == '-' && argv[from][2] == 0)
+         /* If we have found "--", or a "-x", don't consider any more
+            arguments as options.  */
+         if ((((argv[from][1] == '-') || (argv[from][1] == 'x')) && argv[from][2] == 0)
+             || !strcmp(argv[from], "-scripteval"))
            {
              /* Leave the "--", and everything following it, at the end.  */
              for (; from < argc; from++)
----

Re: (unknown)

[Jim Porter]

On 11/17/2023 7:13 PM, Greg Minshall wrote:
> (i was thinking of writing a test to go with the patch, but the ERT
> framework is maybe a bit awkward for tests of essentially
> shell-command-line functionality.  i may have missed it, but i didn't
> see anything in ./test/Makefile.in that seemed to be aimed at testing
> command-line invocation of Emacs.)

You could probably take some inspiration from the "Synchronous 
processes" section of the file test/lisp/eshell/esh-proc-tests.el. 
Essentially, you can just start a new Emacs instance in your ERT test 
and do whatever you like.

(unknown)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Tue, 12 Mar 2024 23:02:10 -0400 (EDT)
> 
> branch: master
> commit 6b40d557c4a9a4152565c1a1b0da49a1aaaec84f
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
> 
>     Port more notification senders to non-XDG systems
>     
>     * doc/lispref/os.texi (Desktop Notifications): Document that
>     `:timeout' is now implemented.
>     
>     * java/org/gnu/emacs/EmacsDesktopNotification.java
>     (EmacsDesktopNotification): New field delay.
>     (display1): Set delay on Android 8.0 and up.
>     
>     * lisp/erc/erc-desktop-notifications.el
>     (erc-notifications-notify): Call Android or Haiku notification
>     functions on those systems.
>     
>     * lisp/gnus/gnus-notifications.el (gnus-notifications-action)
>     (gnus-notification-close): Remove dismissed notifications from
>     the notification to message map.
>     (gnus-notifications-notify): Call android-notifications-notify
>     if possible.
>     
>     * src/androidselect.c (android_init_emacs_desktop_notification):
>     Update accordingly.
>     (android_notifications_notify_1): New argument TIMEOUT.
>     (Fandroid_notifications_notify): New argument QCtimeout.
>     (syms_of_androidselect) <QCtimeout>: New symbol.

This causes the following byte-compilation warning:

  In gnus-notification-close:
  gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'