From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 11:20:27 2025 Received: (at submit) by debbugs.gnu.org; 7 Aug 2025 15:20:27 +0000 Received: from localhost ([127.0.0.1]:35530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk2Pq-0005PT-Lc for submit@debbugs.gnu.org; Thu, 07 Aug 2025 11:20:27 -0400 Received: from lists.gnu.org ([2001:470:142::17]:53584) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk2Pl-0005OF-Qa for submit@debbugs.gnu.org; Thu, 07 Aug 2025 11:20:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uk2PM-0003Dz-89 for bug-gnu-emacs@gnu.org; Thu, 07 Aug 2025 11:19:57 -0400 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uk2PJ-0007Px-1V for bug-gnu-emacs@gnu.org; Thu, 07 Aug 2025 11:19:54 -0400 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-55b87e13a85so1214301e87.3 for ; Thu, 07 Aug 2025 08:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754579990; x=1755184790; darn=gnu.org; h=to:date:message-id:subject:mime-version:from:sender:from:to:cc :subject:date:message-id:reply-to; bh=kmk+PXDclw4iar5K7bxtq0l+ZQE4367xRhRsGpLp1/g=; b=krtGtXZnKlDYUqy/k3VN/V7WqL6TyKs2xGV9w9/DCshh/jVQTSXil9dgWZWxEOFO+d 7AF5pQBiSuowSwbjjeYPv41VP983hJPEunCK/EDSVPw6RiLbK++mcYS6S7Mh6M2061TP 2MNLciob2ijl7k85KggT1GWsLnYDVengfZrKzi30tLJ+QLoXKQRSfzk2l/1XH/tYR+DR Ssl1DsqPkHX1/PGR7PWBzXjELr6BwsjGcTrvy58Wz4Ofywh9OeApLuOBYuJaD38MfFS0 AfUtujC2w8sGFQH11OgXkInfAGMSy+1UA6mjYTnA85rGULB7N+tlrChBtnPynLf78OFf 5pvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754579990; x=1755184790; h=to:date:message-id:subject:mime-version:from:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kmk+PXDclw4iar5K7bxtq0l+ZQE4367xRhRsGpLp1/g=; b=DMb7grjTvPKliS3huos9hVK0eyc+mNTCPjQuok/L2tUr62KpK/mgj3kl6wztv+yiGJ Fk3HCEeTBQ5R/GkdT2FLtKvB66Un6CTmVVVo/QtG3LDJ16h93ORygp11AoyniZg5tUXr ZSb/gCzK/D4TC/4oTxX0ig3l0Hw1ZxuCdu5c+ta5pGjOURss8lPHIN+N1Ieshf8q7E4C 0cvnNm/nlT6OUS81j3z9/X/vmr3SHj93qjGCtu0UV8GowH8PGak+8vOc9viqOA6I2wkC WD3Gtes2U/PhvrrcftKwEGLnihijla7tNtlUdskCbHfBD3lZz9lQLWNtv17GIdM8IQ+D /u3g== X-Gm-Message-State: AOJu0YxkebrkyQAIsiQJFnGuX5i/gi4AMQGAoV37Ao39wayCWdyeGeLj 6Wr1X5mibWH0to0SNEpaTF6lHweEnC3yWYqcXjg9uKrK0HY78eZ6bolAq60iIg== X-Gm-Gg: ASbGnctY+umxtNkv/oFYV/3dTs++Fq1UMoyj80tGoALuvLesfZ9lIXWXf0dGYyDjHG/ PfrhSTz7bGQSoiohlmEzLFASOpQ6pJ7klzpLtsCq6pZCncJi4OLjlptHFRgZO6gQCg3DUabq91W f9qcyIPGvQn/HaXJcf4lgFHfCoND2EwyHQBjT1e3BhnsBy6cnlrlGfykkKtapS485/uCoHks07i 48W3iJgDtp8xd7URyXan28q2PhZpWvaVhGX9/mfa0atZWf5k6cGdM2tvn+1tfzpcvySkANouAGa fGLLdLWCfm9/R/hZMhEAxnmJTiLgjFo84o4/IlyL68zyjXzCAaB5VVjiC2bFxt19CiiaGt1FQ+B Y+zwTC55fvawWnPySgPCjyNfLEmTgSyJ+bOQZpf3R4LArr6DFsh0akG1sYWB6A8/NolwAC893Vw W77NLvFRs0CGNFqZ8bdM47SeM= X-Google-Smtp-Source: AGHT+IEX6YdOOtAInE41ru36dpsuYoVSoM+7xlsGjU/18iIahabG8VhlWqxwkIOMUnIP4RzHtec+cg== X-Received: by 2002:a05:6512:4010:b0:55b:9144:6924 with SMTP id 2adb3069b0e04-55caf51e2b1mr2449023e87.3.1754579990092; Thu, 07 Aug 2025 08:19:50 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55b88ca2d29sm2724297e87.124.2025.08.07.08.19.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2025 08:19:49 -0700 (PDT) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: multipart/mixed; boundary="Apple-Mail=_697DAAEA-C7DC-4D8D-B36D-10DFFCF090FD" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: json parsing error position reform Message-Id: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> Date: Thu, 7 Aug 2025 17:19:48 +0200 To: Emacs Bug Report X-Mailer: Apple Mail (2.3654.120.0.1.15) Received-SPF: pass client-ip=2a00:1450:4864:20::134; envelope-from=mattias.engdegard@gmail.com; helo=mail-lf1-x134.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --Apple-Mail=_697DAAEA-C7DC-4D8D-B36D-10DFFCF090FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The json parser (src/json.c) spends a surprising amount of time keeping = track of the current line and column, on the off chance that an error = occurs in which case that information would helpfully be included. This = is a bad design in a variety of ways: (1) It goes against all performance engineering to spend resources on = maintaining information that is unlikely to be used. (2) JSON parse errors aren't expected to occur during normal operation. (3) =46rom what I can tell, nobody uses the position information of the = json-error signal at all. (4) One reason for (3) is that it isn't documented anywhere. (5) Even if someone would find the position useful, there is no evidence = that they would need the line and column (which could easily be derived = from the position). So let's remove at least the line and column of the error position. We = can still supply the position from the start of the parse because we = have the information anyway. There's a patch. Surprisingly, it speeds up the parsing part by more = than 10 % which is definitely worthwhile. --Apple-Mail=_697DAAEA-C7DC-4D8D-B36D-10DFFCF090FD Content-Disposition: attachment; filename=jsonspeed.diff Content-Type: application/octet-stream; x-unix-mode=0644; name="jsonspeed.diff" Content-Transfer-Encoding: quoted-printable =20src/json.c=20=20=20=20=20=20=20=20=20=20=20=20=20|=20182=20= ++++++++++++++++++++++++++-----------------------=0A=20= test/src/json-tests.el=20|=20=2029=20++++++++=0A=202=20files=20changed,=20= 124=20insertions(+),=2087=20deletions(-)=0A=0Adiff=20--git=20= a/src/json.c=20b/src/json.c=0Aindex=2044eae653eb5..77291cde56a=20100644=0A= ---=20a/src/json.c=0A+++=20b/src/json.c=0A@@=20-684,10=20+684,6=20@@=20= #define=20JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE=20512=0A=20=20=20= const=20unsigned=20char=20*secondary_input_begin;=0A=20=20=20const=20= unsigned=20char=20*secondary_input_end;=0A=20=0A-=20=20ptrdiff_t=20= current_line;=0A-=20=20ptrdiff_t=20current_column;=0A-=20=20ptrdiff_t=20= point_of_current_line;=0A-=0A=20=20=20/*=20The=20parser=20has=20a=20= maximum=20allowed=20depth.=20=20available_depth=0A=20=20=20=20=20=20= decreases=20at=20each=20object/array=20begin.=20=20If=20reaches=20zero,=20= then=20an=0A=20=20=20=20=20=20error=20is=20generated=20*/=0A@@=20-717,15=20= +713,18=20@@=20#define=20JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE=20512=0A= =20=20=20unsigned=20char=20*byte_workspace;=0A=20=20=20unsigned=20char=20= *byte_workspace_end;=0A=20=20=20unsigned=20char=20= *byte_workspace_current;=0A+=0A+=20=20Lisp_Object=20obj;=0A+=20=20= ptrdiff_t=20(*byte_to_pos)=20(Lisp_Object=20obj,=20ptrdiff_t=20byte);=0A=20= };=0A=20=0A=20static=20AVOID=0A-json_signal_error=20(struct=20= json_parser=20*parser,=20Lisp_Object=20error)=0A+json_signal_error=20= (struct=20json_parser=20*p,=20Lisp_Object=20error)=0A=20{=0A-=20=20= xsignal3=20(error,=20INT_TO_INTEGER=20(parser->current_line),=0A-=09=20=20= =20=20INT_TO_INTEGER=20(parser->current_column),=0A-=09=20=20=20=20= INT_TO_INTEGER=20(parser->point_of_current_line=0A-=09=09=09=20=20=20=20= +=20parser->current_column));=0A+=20=20ptrdiff_t=20byte=20=3D=20= (p->input_current=20-=20p->input_begin=0A+=09=09=20=20=20=20+=20= p->additional_bytes_count);=0A+=20=20ptrdiff_t=20pos=20=3D=20= p->byte_to_pos=20(p->obj,=20byte);=0A+=20=20xsignal1=20(error,=20= INT_TO_INTEGER=20(pos));=0A=20}=0A=20=0A=20static=20void=0A@@=20-734,7=20= +733,9=20@@=20json_parser_init=20(struct=20json_parser=20*parser,=0A=20=09= =09=20=20const=20unsigned=20char=20*input,=0A=20=09=09=20=20const=20= unsigned=20char=20*input_end,=0A=20=09=09=20=20const=20unsigned=20char=20= *secondary_input,=0A-=09=09=20=20const=20unsigned=20char=20= *secondary_input_end)=0A+=09=09=20=20const=20unsigned=20char=20= *secondary_input_end,=0A+=09=09=20=20ptrdiff_t=20(*byte_to_pos)=20= (Lisp_Object,=20ptrdiff_t),=0A+=09=09=20=20Lisp_Object=20obj)=0A=20{=0A=20= =20=20if=20(secondary_input=20>=3D=20secondary_input_end)=0A=20=20=20=20=20= {=0A@@=20-761,9=20+762,6=20@@=20json_parser_init=20(struct=20json_parser=20= *parser,=0A=20=0A=20=20=20parser->input_current=20=3D=20= parser->input_begin;=0A=20=0A-=20=20parser->current_line=20=3D=201;=0A-=20= =20parser->current_column=20=3D=200;=0A-=20=20= parser->point_of_current_line=20=3D=200;=0A=20=20=20= parser->available_depth=20=3D=2010000;=0A=20=20=20parser->conf=20=3D=20= conf;=0A=20=0A@@=20-777,6=20+775,8=20@@=20json_parser_init=20(struct=20= json_parser=20*parser,=0A=20=20=20parser->byte_workspace=20=3D=20= parser->internal_byte_workspace;=0A=20=20=20parser->byte_workspace_end=20= =3D=20(parser->byte_workspace=0A=20=09=09=09=09+=20= JSON_PARSER_INTERNAL_BYTE_WORKSPACE_SIZE);=0A+=20=20parser->byte_to_pos=20= =3D=20byte_to_pos;=0A+=20=20parser->obj=20=3D=20obj;=0A=20}=0A=20=0A=20= static=20void=0A@@=20-956,20=20+956,9=20@@=20json_input_put_back=20= (struct=20json_parser=20*parser)=0A=20}=0A=20=0A=20static=20bool=0A= -json_skip_whitespace_internal=20(struct=20json_parser=20*parser,=20int=20= c)=0A+is_json_whitespace=20(int=20c)=0A=20{=0A-=20=20= parser->current_column++;=0A-=20=20if=20(c=20=3D=3D=200x20=20||=20c=20=3D=3D= =200x09=20||=20c=20=3D=3D=200x0d)=0A-=20=20=20=20return=20false;=0A-=20=20= else=20if=20(c=20=3D=3D=200x0a)=0A-=20=20=20=20{=0A-=20=20=20=20=20=20= parser->current_line++;=0A-=20=20=20=20=20=20= parser->point_of_current_line=20+=3D=20parser->current_column;=0A-=20=20=20= =20=20=20parser->current_column=20=3D=200;=0A-=20=20=20=20=20=20return=20= false;=0A-=20=20=20=20}=0A-=20=20else=0A-=20=20=20=20return=20true;=0A+=20= =20return=20c=20=3D=3D=200x20=20||=20c=20=3D=3D=200x09=20||=20c=20=3D=3D=20= 0x0d=20||=20c=20=3D=3D=200x0a;=0A=20}=0A=20=0A=20/*=20Skips=20JSON=20= whitespace,=20and=20returns=20with=20the=20first=20non-whitespace=0A@@=20= -980,7=20+969,7=20@@=20json_skip_whitespace=20(struct=20json_parser=20= *parser)=0A=20=20=20for=20(;;)=0A=20=20=20=20=20{=0A=20=20=20=20=20=20=20= int=20c=20=3D=20json_input_get=20(parser);=0A-=20=20=20=20=20=20if=20= (json_skip_whitespace_internal=20(parser,=20c))=0A+=20=20=20=20=20=20if=20= (!is_json_whitespace=20(c))=0A=20=09return=20c;=0A=20=20=20=20=20}=0A=20= }=0A@@=20-994,9=20+983,7=20@@=20json_skip_whitespace_if_possible=20= (struct=20json_parser=20*parser)=0A=20=20=20for=20(;;)=0A=20=20=20=20=20= {=0A=20=20=20=20=20=20=20int=20c=20=3D=20json_input_get_if_possible=20= (parser);=0A-=20=20=20=20=20=20if=20(c=20<=200)=0A-=09return=20c;=0A-=20=20= =20=20=20=20if=20(json_skip_whitespace_internal=20(parser,=20c))=0A+=20=20= =20=20=20=20if=20(!is_json_whitespace=20(c)=20||=20c=20<=200)=0A=20=09= return=20c;=0A=20=20=20=20=20}=0A=20}=0A@@=20-1022,7=20+1009,6=20@@=20= json_parse_unicode=20(struct=20json_parser=20*parser)=0A=20=20=20for=20= (int=20i=20=3D=200;=20i=20<=204;=20i++)=0A=20=20=20=20=20{=0A=20=20=20=20= =20=20=20int=20c=20=3D=20json_hex_value=20(json_input_get=20(parser));=0A= -=20=20=20=20=20=20parser->current_column++;=0A=20=20=20=20=20=20=20if=20= (c=20<=200)=0A=20=09json_signal_error=20(parser,=20= Qjson_escape_sequence_error);=0A=20=20=20=20=20=20=20v[i]=20=3D=20c;=0A= @@=20-1068,13=20+1054,11=20@@=20json_parse_string=20(struct=20= json_parser=20*parser,=20bool=20intern,=20bool=20leading_colon)=0A=20=09=20= =20=20=20=20=20json_byte_workspace_put=20(parser,=20c2);=0A=20=09=20=20=20= =20=20=20json_byte_workspace_put=20(parser,=20c3);=0A=20=09=20=20=20=20=20= =20parser->input_current=20+=3D=204;=0A-=09=20=20=20=20=20=20= parser->current_column=20+=3D=204;=0A=20=09=20=20=20=20=20=20continue;=0A= =20=09=20=20=20=20}=0A=20=09}=0A=20=0A=20=20=20=20=20=20=20int=20c=20=3D=20= json_input_get=20(parser);=0A-=20=20=20=20=20=20= parser->current_column++;=0A=20=20=20=20=20=20=20if=20= (json_plain_char[c])=0A=20=09{=0A=20=09=20=20json_byte_workspace_put=20= (parser,=20c);=0A@@=20-1137,7=20+1121,6=20@@=20json_parse_string=20= (struct=20json_parser=20*parser,=20bool=20intern,=20bool=20= leading_colon)=0A=20=09{=0A=20=09=20=20/*=20Handle=20escape=20sequences=20= */=0A=20=09=20=20c=20=3D=20json_input_get=20(parser);=0A-=09=20=20= parser->current_column++;=0A=20=09=20=20if=20(c=20=3D=3D=20'"')=0A=20=09=20= =20=20=20json_byte_workspace_put=20(parser,=20'"');=0A=20=09=20=20else=20= if=20(c=20=3D=3D=20'\\')=0A@@=20-1160,11=20+1143,9=20@@=20= json_parse_string=20(struct=20json_parser=20*parser,=20bool=20intern,=20= bool=20leading_colon)=0A=20=09=20=20=20=20=20=20/*=20is=20the=20first=20= half=20of=20the=20surrogate=20pair=20*/=0A=20=09=20=20=20=20=20=20if=20= (num=20>=3D=200xd800=20&&=20num=20<=200xdc00)=0A=20=09=09{=0A-=09=09=20=20= parser->current_column++;=0A=20=09=09=20=20if=20(json_input_get=20= (parser)=20!=3D=20'\\')=0A=20=09=09=20=20=20=20json_signal_error=20= (parser,=0A=20=09=09=09=09=20=20=20=20=20=20=20= Qjson_invalid_surrogate_error);=0A-=09=09=20=20parser->current_column++;=0A= =20=09=09=20=20if=20(json_input_get=20(parser)=20!=3D=20'u')=0A=20=09=09=20= =20=20=20json_signal_error=20(parser,=0A=20=09=09=09=09=20=20=20=20=20=20= =20Qjson_invalid_surrogate_error);=0A@@=20-1285,7=20+1266,6=20@@=20= json_parse_number=20(struct=20json_parser=20*parser,=20int=20c)=0A=20=20=20= =20=20=20=20negative=20=3D=20true;=0A=20=20=20=20=20=20=20c=20=3D=20= json_input_get=20(parser);=0A=20=20=20=20=20=20=20= json_byte_workspace_put=20(parser,=20c);=0A-=20=20=20=20=20=20= parser->current_column++;=0A=20=20=20=20=20}=0A=20=20=20if=20(c=20<=20= '0'=20||=20c=20>=20'9')=0A=20=20=20=20=20json_signal_error=20(parser,=20= Qjson_parse_error);=0A@@=20-1317,7=20+1297,6=20@@=20json_parse_number=20= (struct=20json_parser=20*parser,=20int=20c)=0A=20=09=20=20if=20(c=20<=20= '0'=20||=20c=20>=20'9')=0A=20=09=20=20=20=20break;=0A=20=09=20=20= json_byte_workspace_put=20(parser,=20c);=0A-=09=20=20= parser->current_column++;=0A=20=0A=20=09=20=20integer_overflow=20|=3D=20= ckd_mul=20(&integer,=20integer,=2010);=0A=20=09=20=20integer_overflow=20= |=3D=20ckd_add=20(&integer,=20integer,=20c=20-=20'0');=0A@@=20-1328,12=20= +1307,10=20@@=20json_parse_number=20(struct=20json_parser=20*parser,=20= int=20c)=0A=20=20=20if=20(c=20=3D=3D=20'.')=0A=20=20=20=20=20{=0A=20=20=20= =20=20=20=20json_byte_workspace_put=20(parser,=20c);=0A-=20=20=20=20=20=20= parser->current_column++;=0A=20=0A=20=20=20=20=20=20=20is_float=20=3D=20= true;=0A=20=20=20=20=20=20=20c=20=3D=20json_input_get=20(parser);=0A=20=20= =20=20=20=20=20json_byte_workspace_put=20(parser,=20c);=0A-=20=20=20=20=20= =20parser->current_column++;=0A=20=20=20=20=20=20=20if=20(c=20<=20'0'=20= ||=20c=20>=20'9')=0A=20=09json_signal_error=20(parser,=20= Qjson_parse_error);=0A=20=20=20=20=20=20=20for=20(;;)=0A@@=20-1344,23=20= +1321,19=20@@=20json_parse_number=20(struct=20json_parser=20*parser,=20= int=20c)=0A=20=09=20=20if=20(c=20<=20'0'=20||=20c=20>=20'9')=0A=20=09=20=20= =20=20break;=0A=20=09=20=20json_byte_workspace_put=20(parser,=20c);=0A-=09= =20=20parser->current_column++;=0A=20=09}=0A=20=20=20=20=20}=0A=20=20=20= if=20(c=20=3D=3D=20'e'=20||=20c=20=3D=3D=20'E')=0A=20=20=20=20=20{=0A=20=20= =20=20=20=20=20json_byte_workspace_put=20(parser,=20c);=0A-=20=20=20=20=20= =20parser->current_column++;=0A=20=0A=20=20=20=20=20=20=20is_float=20=3D=20= true;=0A=20=20=20=20=20=20=20c=20=3D=20json_input_get=20(parser);=0A=20=20= =20=20=20=20=20json_byte_workspace_put=20(parser,=20c);=0A-=20=20=20=20=20= =20parser->current_column++;=0A=20=20=20=20=20=20=20if=20(c=20=3D=3D=20= '-'=20||=20c=20=3D=3D=20'+')=0A=20=09{=0A=20=09=20=20c=20=3D=20= json_input_get=20(parser);=0A=20=09=20=20json_byte_workspace_put=20= (parser,=20c);=0A-=09=20=20parser->current_column++;=0A=20=09}=0A=20=20=20= =20=20=20=20if=20(c=20<=20'0'=20||=20c=20>=20'9')=0A=20=09= json_signal_error=20(parser,=20Qjson_parse_error);=0A@@=20-1372,7=20= +1345,6=20@@=20json_parse_number=20(struct=20json_parser=20*parser,=20= int=20c)=0A=20=09=20=20if=20(c=20<=20'0'=20||=20c=20>=20'9')=0A=20=09=20=20= =20=20break;=0A=20=09=20=20json_byte_workspace_put=20(parser,=20c);=0A-=09= =20=20parser->current_column++;=0A=20=09}=0A=20=20=20=20=20}=0A=20=0A@@=20= -1605,57=20+1577,67=20@@=20json_is_token_char=20(int=20c)=0A=20=09=20=20= ||=20(c=20>=3D=20'0'=20&&=20c=20<=3D=20'9')=20||=20(c=20=3D=3D=20'-'));=0A= =20}=0A=20=0A-/*=20This=20is=20the=20entry=20point=20to=20the=20value=20= parser,=20this=20parses=20a=20JSON=0A-=20*=20value=20*/=0A-Lisp_Object=0A= +static=20Lisp_Object=0A=20json_parse_value=20(struct=20json_parser=20= *parser,=20int=20c)=0A=20{=0A-=20=20if=20(c=20=3D=3D=20'{')=0A-=20=20=20=20= return=20json_parse_object=20(parser);=0A-=20=20else=20if=20(c=20=3D=3D=20= '[')=0A-=20=20=20=20return=20json_parse_array=20(parser);=0A-=20=20else=20= if=20(c=20=3D=3D=20'"')=0A-=20=20=20=20return=20json_parse_string=20= (parser,=20false,=20false);=0A-=20=20else=20if=20((c=20>=3D=20'0'=20&&=20= c=20<=3D=20'9')=20||=20(c=20=3D=3D=20'-'))=0A-=20=20=20=20return=20= json_parse_number=20(parser,=20c);=0A-=20=20else=0A+=20=20switch=20(c)=0A= =20=20=20=20=20{=0A-=20=20=20=20=20=20int=20c2=20=3D=20= json_input_get_if_possible=20(parser);=0A-=20=20=20=20=20=20int=20c3=20=3D= =20json_input_get_if_possible=20(parser);=0A-=20=20=20=20=20=20int=20c4=20= =3D=20json_input_get_if_possible=20(parser);=0A-=20=20=20=20=20=20int=20= c5=20=3D=20json_input_get_if_possible=20(parser);=0A-=0A-=20=20=20=20=20=20= if=20(c=20=3D=3D=20't'=20&&=20c2=20=3D=3D=20'r'=20&&=20c3=20=3D=3D=20'u'=20= &&=20c4=20=3D=3D=20'e'=0A-=09=20=20&&=20(c5=20<=200=20||=20= !json_is_token_char=20(c5)))=0A+=20=20=20=20case=20'{':=0A+=20=20=20=20=20= =20return=20json_parse_object=20(parser);=0A+=20=20=20=20case=20'[':=0A+=20= =20=20=20=20=20return=20json_parse_array=20(parser);=0A+=20=20=20=20case=20= '"':=0A+=20=20=20=20=20=20return=20json_parse_string=20(parser,=20false,=20= false);=0A+=20=20=20=20case=20'0':=20case=20'1':=20case=20'2':=20case=20= '3':=20case=20'4':=0A+=20=20=20=20case=20'5':=20case=20'6':=20case=20= '7':=20case=20'8':=20case=20'9':=0A+=20=20=20=20case=20'-':=0A+=20=20=20=20= =20=20return=20json_parse_number=20(parser,=20c);=0A+=20=20=20=20case=20= 't':=0A+=20=20=20=20=20=20if=20(json_input_get_if_possible=20(parser)=20= =3D=3D=20'r'=0A+=09=20=20&&=20json_input_get_if_possible=20(parser)=20=3D=3D= =20'u'=0A+=09=20=20&&=20json_input_get_if_possible=20(parser)=20=3D=3D=20= 'e')=0A=20=09{=0A-=09=20=20if=20(c5=20>=3D=200)=0A-=09=20=20=20=20= json_input_put_back=20(parser);=0A-=09=20=20parser->current_column=20+=3D=20= 3;=0A-=09=20=20return=20Qt;=0A+=09=20=20int=20c2=20=3D=20= json_input_get_if_possible=20(parser);=0A+=09=20=20if=20= (!json_is_token_char=20(c2))=0A+=09=20=20=20=20{=0A+=09=20=20=20=20=20=20= if=20(c2=20>=3D=200)=0A+=09=09json_input_put_back=20(parser);=0A+=09=20=20= =20=20=20=20return=20Qt;=0A+=09=20=20=20=20}=0A=20=09}=0A-=20=20=20=20=20= =20if=20(c=20=3D=3D=20'n'=20&&=20c2=20=3D=3D=20'u'=20&&=20c3=20=3D=3D=20= 'l'=20&&=20c4=20=3D=3D=20'l'=0A-=09=20=20&&=20(c5=20<=200=20||=20= !json_is_token_char=20(c5)))=0A+=20=20=20=20=20=20break;=0A+=20=20=20=20= case=20'f':=0A+=20=20=20=20=20=20if=20(json_input_get_if_possible=20= (parser)=20=3D=3D=20'a'=0A+=09=20=20&&=20json_input_get_if_possible=20= (parser)=20=3D=3D=20'l'=0A+=09=20=20&&=20json_input_get_if_possible=20= (parser)=20=3D=3D=20's'=0A+=09=20=20&&=20json_input_get_if_possible=20= (parser)=20=3D=3D=20'e')=0A=20=09{=0A-=09=20=20if=20(c5=20>=3D=200)=0A-=09= =20=20=20=20json_input_put_back=20(parser);=0A-=09=20=20= parser->current_column=20+=3D=203;=0A-=09=20=20return=20= parser->conf.null_object;=0A+=09=20=20int=20c2=20=3D=20= json_input_get_if_possible=20(parser);=0A+=09=20=20if=20= (!json_is_token_char=20(c2))=0A+=09=20=20=20=20{=0A+=09=20=20=20=20=20=20= if=20(c2=20>=3D=200)=0A+=09=09json_input_put_back=20(parser);=0A+=09=20=20= =20=20=20=20return=20parser->conf.false_object;=0A+=09=20=20=20=20}=0A=20= =09}=0A-=20=20=20=20=20=20if=20(c=20=3D=3D=20'f'=20&&=20c2=20=3D=3D=20= 'a'=20&&=20c3=20=3D=3D=20'l'=20&&=20c4=20=3D=3D=20's'=0A-=09=20=20&&=20= c5=20=3D=3D=20'e')=0A+=20=20=20=20=20=20break;=0A+=20=20=20=20case=20= 'n':=0A+=20=20=20=20=20=20if=20(json_input_get_if_possible=20(parser)=20= =3D=3D=20'u'=0A+=09=20=20&&=20json_input_get_if_possible=20(parser)=20=3D=3D= =20'l'=0A+=09=20=20&&=20json_input_get_if_possible=20(parser)=20=3D=3D=20= 'l')=0A=20=09{=0A-=09=20=20int=20c6=20=3D=20json_input_get_if_possible=20= (parser);=0A-=09=20=20if=20(c6=20<=200=20||=20!json_is_token_char=20= (c6))=0A+=09=20=20int=20c2=20=3D=20json_input_get_if_possible=20= (parser);=0A+=09=20=20if=20(!json_is_token_char=20(c2))=0A=20=09=20=20=20= =20{=0A-=09=20=20=20=20=20=20if=20(c6=20>=3D=200)=0A+=09=20=20=20=20=20=20= if=20(c2=20>=3D=200)=0A=20=09=09json_input_put_back=20(parser);=0A-=09=20= =20=20=20=20=20parser->current_column=20+=3D=204;=0A-=09=20=20=20=20=20=20= return=20parser->conf.false_object;=0A+=09=20=20=20=20=20=20return=20= parser->conf.null_object;=0A=20=09=20=20=20=20}=0A=20=09}=0A-=0A-=20=20=20= =20=20=20json_signal_error=20(parser,=20Qjson_parse_error);=0A+=20=20=20=20= =20=20break;=0A=20=20=20=20=20}=0A+=0A+=20=20json_signal_error=20= (parser,=20Qjson_parse_error);=0A=20}=0A=20=0A=20static=20Lisp_Object=0A= @@=20-1664,6=20+1646,24=20@@=20json_parse=20(struct=20json_parser=20= *parser)=0A=20=20=20return=20json_parse_value=20(parser,=20= json_skip_whitespace=20(parser));=0A=20}=0A=20=0A+/*=20Count=20number=20= of=20characters=20in=20the=20NBYTES=20of=20bytes=20at=20S.=20=20*/=0A= +static=20ptrdiff_t=0A+count_chars=20(const=20unsigned=20char=20*s,=20= ptrdiff_t=20nbytes)=0A+{=0A+=20=20ptrdiff_t=20nchars=20=3D=200;=0A+=20=20= for=20(ptrdiff_t=20i=20=3D=200;=20i=20<=20nbytes;=20i++)=0A+=20=20=20=20= nchars=20+=3D=20(s[i]=20&=200xc0)=20!=3D=200x80;=0A+=20=20return=20= nchars;=0A+}=0A+=0A+static=20ptrdiff_t=0A+json_string_byte_to_pos=20= (Lisp_Object=20obj,=20ptrdiff_t=20byte)=0A+{=0A+=20=20eassert=20(STRINGP=20= (obj));=0A+=20=20eassert=20(byte=20<=3D=20SBYTES=20(obj));=0A+=20=20= return=20STRING_MULTIBYTE=20(obj)=20?=20count_chars=20(SDATA=20(obj),=20= byte)=20:=20byte;=0A+}=0A+=0A=20DEFUN=20("json-parse-string",=20= Fjson_parse_string,=20Sjson_parse_string,=201,=20MANY,=0A=20=20=20=20=20=20= =20=20NULL,=0A=20=20=20=20=20=20=20=20doc:=20/*=20Parse=20the=20JSON=20= STRING=20into=20a=20Lisp=20value.=0A@@=20-1703,7=20+1703,8=20@@=20DEFUN=20= ("json-parse-string",=20Fjson_parse_string,=20Sjson_parse_string,=201,=20= MANY,=0A=20=0A=20=20=20struct=20json_parser=20p;=0A=20=20=20const=20= unsigned=20char=20*begin=20=3D=20SDATA=20(string);=0A-=20=20= json_parser_init=20(&p,=20conf,=20begin,=20begin=20+=20SBYTES=20= (string),=20NULL,=20NULL);=0A+=20=20json_parser_init=20(&p,=20conf,=20= begin,=20begin=20+=20SBYTES=20(string),=20NULL,=20NULL,=0A+=09=09=20=20=20= =20json_string_byte_to_pos,=20string);=0A=20=20=20= record_unwind_protect_ptr=20(json_parser_done,=20&p);=0A=20=20=20= Lisp_Object=20result=20=3D=20json_parse=20(&p);=0A=20=0A@@=20-1713,6=20= +1714,13=20@@=20DEFUN=20("json-parse-string",=20Fjson_parse_string,=20= Sjson_parse_string,=201,=20MANY,=0A=20=20=20return=20unbind_to=20(count,=20= result);=0A=20}=0A=20=0A+static=20ptrdiff_t=0A+json_buffer_byte_to_pos=20= (Lisp_Object=20obj,=20ptrdiff_t=20byte)=0A+{=0A+=20=20/*=20The=20= position=20from=20the=20start=20of=20the=20parse=20(for=20= compatibility).=20=20*/=0A+=20=20return=20BYTE_TO_CHAR=20(PT_BYTE=20+=20= byte)=20-=20PT;=0A+}=0A+=0A=20DEFUN=20("json-parse-buffer",=20= Fjson_parse_buffer,=20Sjson_parse_buffer,=0A=20=20=20=20=20=20=20=200,=20= MANY,=20NULL,=0A=20=20=20=20=20=20=20=20doc:=20/*=20Read=20a=20JSON=20= value=20from=20current=20buffer=20starting=20at=20point.=0A@@=20-1766,8=20= +1774,8=20@@=20DEFUN=20("json-parse-buffer",=20Fjson_parse_buffer,=20= Sjson_parse_buffer,=0A=20=20=20=20=20=20=20secondary_end=20=3D=20= ZV_ADDR;=0A=20=20=20=20=20}=0A=20=0A-=20=20json_parser_init=20(&p,=20= conf,=20begin,=20end,=20secondary_begin,=0A-=09=09=20=20=20=20= secondary_end);=0A+=20=20json_parser_init=20(&p,=20conf,=20begin,=20end,=20= secondary_begin,=20secondary_end,=0A+=09=09=20=20=20=20= json_buffer_byte_to_pos,=20Qnil);=0A=20=20=20record_unwind_protect_ptr=20= (json_parser_done,=20&p);=0A=20=20=20Lisp_Object=20result=20=3D=20= json_parse=20(&p);=0A=20=0A@@=20-1776,7=20+1784,7=20@@=20DEFUN=20= ("json-parse-buffer",=20Fjson_parse_buffer,=20Sjson_parse_buffer,=0A=20=20= =20ptrdiff_t=20position=20=3D=20(NILP=20(BVAR=20(current_buffer,=0A=20=09= =09=09=09=20=20=20=20enable_multibyte_characters))=0A=20=09=09=09?=20= byte=0A-=09=09=09:=20PT=20+=20p.point_of_current_line=20+=20= p.current_column);=0A+=09=09=09:=20BYTE_TO_CHAR=20(byte));=0A=20=20=20= SET_PT_BOTH=20(position,=20byte);=0A=20=0A=20=20=20return=20unbind_to=20= (count,=20result);=0Adiff=20--git=20a/test/src/json-tests.el=20= b/test/src/json-tests.el=0Aindex=201cb667ddeac..a8a70d245a2=20100644=0A= ---=20a/test/src/json-tests.el=0A+++=20b/test/src/json-tests.el=0A@@=20= -424,5=20+424,34=20@@=20json-serialize/wrong-hash-key-type=0A=20=20=20=20= =20(puthash=201=202=20table)=0A=20=20=20=20=20(should-error=20= (json-serialize=20table)=20:type=20'wrong-type-argument)))=0A=20=0A= +(defun=20json-tests--parse-string-error-pos=20(s)=0A+=20=20= (condition-case=20e=0A+=20=20=20=20=20=20(json-parse-string=20s)=0A+=20=20= =20=20(json-error=20(nth=201=20e))=0A+=20=20=20=20(:success=20'no-error=20= e)))=0A+=0A+(defun=20json-tests--parse-buffer-error-pos=20()=0A+=20=20= (condition-case=20e=0A+=20=20=20=20=20=20(json-parse-buffer)=0A+=20=20=20= =20(json-error=20(nth=201=20e))=0A+=20=20=20=20(:success=20'no-error=20= e)))=0A+=0A+(ert-deftest=20json-parse-error-position=20()=0A+=20=20(let*=20= ((s=20"[\"*=CE=A9=C3=9F=C5=93=E2=98=83*\",,8]")=0A+=20=20=20=20=20=20=20=20= =20(su=20(encode-coding-string=20s=20'utf-8-emacs)))=0A+=20=20=20=20= (should=20(equal=20(json-tests--parse-string-error-pos=20s)=2011))=0A+=20= =20=20=20(should=20(equal=20(json-tests--parse-string-error-pos=20su)=20= 16))=0A+=0A+=20=20=20=20(with-temp-buffer=0A+=20=20=20=20=20=20(let=20= ((junk=20"some=20leading=20junk"))=0A+=20=20=20=20=20=20=20=20(insert=20= junk)=0A+=20=20=20=20=20=20=20=20(insert=20s)=0A+=20=20=20=20=20=20=20=20= (goto-char=20(1+=20(length=20junk)))=0A+=20=20=20=20=20=20=20=20(should=20= (equal=20(json-tests--parse-buffer-error-pos)=2011))=0A+=0A+=20=20=20=20=20= =20=20=20(set-buffer-multibyte=20nil)=0A+=20=20=20=20=20=20=20=20= (goto-char=20(1+=20(length=20junk)))=0A+=20=20=20=20=20=20=20=20(should=20= (equal=20(json-tests--parse-buffer-error-pos)=2016))))))=0A+=0A=20= (provide=20'json-tests)=0A=20;;;=20json-tests.el=20ends=20here=0A= --Apple-Mail=_697DAAEA-C7DC-4D8D-B36D-10DFFCF090FD-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 11:37:04 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 15:37:04 +0000 Received: from localhost ([127.0.0.1]:35566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk2fv-0006Bb-Rt for submit@debbugs.gnu.org; Thu, 07 Aug 2025 11:37:04 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58962) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk2ft-0006B1-HA for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 11:37:02 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uk2fo-0002fe-5v; Thu, 07 Aug 2025 11:36:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=3ictgaGPuXGDZohq2j2NXNYC5N1UdzQz9rObbMjdkzY=; b=Y/cvZFyT5R8D1rD7X6s+ gKYfheof3krVSAJX6VXWFmD5OvPV4afWeUheO4lFESydr6OxuvPgZkuUsmvS0txZSLAHIXoBURe51 VHxxeJoboF3j0DEsipMwGEB/6w/7OS/2Z3eBQZ4r6xh2+DlGHStBkL+sEXDm+29GnVVvoGQmkqu9/ bA8zA31BGYmRfc9appu5ebJqTPJkjLPYG3IlNelQjtuigNXUKfecPvBDUupCNkHSwQIrFdW1hilwC HGAQzT8WyNmLLa8hiqbCIGS0ZeLkV9K2KiC3B94MC5kVJxTashquMzMnPINN8AmAcw6LkfIDW40tP vXn93yDxXwk1IQ==; Date: Thu, 07 Aug 2025 18:36:16 +0300 Message-Id: <86h5yjp2j3.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Thu, 7 Aug 2025 17:19:48 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Thu, 7 Aug 2025 17:19:48 +0200 > > The json parser (src/json.c) spends a surprising amount of time keeping track of the current line and column, on the off chance that an error occurs in which case that information would helpfully be included. This is a bad design in a variety of ways: > > (1) It goes against all performance engineering to spend resources on maintaining information that is unlikely to be used. > (2) JSON parse errors aren't expected to occur during normal operation. > (3) From what I can tell, nobody uses the position information of the json-error signal at all. > (4) One reason for (3) is that it isn't documented anywhere. > (5) Even if someone would find the position useful, there is no evidence that they would need the line and column (which could easily be derived from the position). > > So let's remove at least the line and column of the error position. We can still supply the position from the start of the parse because we have the information anyway. If we have the position, can we have the cake and eat it, too? Would it be possible to call some function in the case of an error that would calculate the line and column from the position, and include that in the error data? That way, the performance will suffer only when there is an error to report. Another idea is to disable this conditionally, so that if someone really needs this, they could have it for the price of somewhat slower parsing. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 11:43:37 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 15:43:37 +0000 Received: from localhost ([127.0.0.1]:35579 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk2mG-0006SJ-JU for submit@debbugs.gnu.org; Thu, 07 Aug 2025 11:43:36 -0400 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:44474) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uk2mE-0006S1-BB for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 11:43:35 -0400 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-55b93104888so1345739e87.1 for <79192@debbugs.gnu.org>; Thu, 07 Aug 2025 08:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754581408; x=1755186208; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=UJBAO1YQXdb9D7Zasn74LyhqJVItxDI9BEIgvL3qRrk=; b=TPv1fIGOsEpok7YVdQ+RZnpLFv1GzqXvdqx3IvpGIP7olQ19hShdKeY37dyhF4UTVB balWFmdaCe/DvgwFeMnX2Eer9Sfb5VlAl/t4b96PsuIp6GiYTO3Bl9Nbex5WWzS6KTT0 bLocOUzcSI/fAWHjjFUSUEKN1sWZzbJueRbVwCFlwR/ABqtYQGM+v9CfQXOZv8jSLlYB aBaAB+RhbuIHvlyGNzBzTs4PbIiQ36GZNrC2G0dVY7GQzt0LIZr01q7ZF5y+xrrzkb6M 8z2E9aTFF1YlNWWaoK+GI99Cbci7BO+MvhNOkjhutx7pxXT0jX8joMNZmeYlQu26+L9S S9Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754581408; x=1755186208; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UJBAO1YQXdb9D7Zasn74LyhqJVItxDI9BEIgvL3qRrk=; b=fGcvNUZLE8PRUt32l5W8i+5RjrscC+QzVjT/9k2z2dwT0IV5OnG9dt04OEgfWUZLUi IBBRkbeIvFHZZ8az2agvwXjy9cHtDOjDbHoSCWZSjoLmjT9sRBRLNRR0pxX1SbetDRSe mDPgoHSJpzAR+l69NY5bDoGKXCS5OlLw8hunjTjBMFom4jLqdCkC+FCbr/46dhIpE1sN tdvmAukoZDt0x+mMWiGGyeA0xIsKQyWSbAoypg0CyBQp8MNrpXsdg+M08WptIr2zY3r6 IWx6G+Z3k/VUcbNEtwMATWJJyvUssuJLnTZR56jpxATHXosooapPVt9wknhkcC10048n eSQQ== X-Gm-Message-State: AOJu0YzXJ7RdJ01zrT9TuPBn1aoTvT3o1/bIe6BjMbRIF2Xk9YMo0w85 MV85MLMZL9UwzlaMms3sAhFmDd5KuSKZGYRPkPapeIxCd2Vwnk70jqPm X-Gm-Gg: ASbGncuIf/Bmtgw/m/xLhZVzxwqbVoi6ZCwBXnuUz8SMMGLHVN4XEytJgMsctodKywI t0tQAmApHfCEnyRGIFTJvk6AtaKPfi9/q4ojBq9QmIu29JtsW1KhD1Xxguo9y6ZYiM57e2HtYIi cdqlv76fsdqprVQv9eGRkYm/ZS+T0nHJh4zm1RjlnaHjLWtqRWV6+pmwsvAREpmtFGUWew0iZRU 6ElRCi+jpZmza2NvIlCq5dS5PHqjXqPfWtuMWeo2lpG7twGBSMspX8TG3bUn3rvgAsmd7coodv4 WCWqOUpgVBedXE9rBM7jMEAsDn0FlBcNeX+oDzxoljMTHdEDU1cVOkhj/RU961JGcMNTJz4kt2F ILeupgd3fBPAf0Qbh6Nc7UihqENwS1a+mvl1QFKew6sts4fSUpZ5xXDuQLUzp6qWrMoCg0sxVOM bEYMcm1JqHUlQC X-Google-Smtp-Source: AGHT+IGkb4PDJFJ4KNF252938UV4L9DLKC9lkoyWT6xsZNdjYw3yHdhdqZOH2E52PUJtjQr5NhVzrQ== X-Received: by 2002:a05:6512:3f02:b0:553:2480:2308 with SMTP id 2adb3069b0e04-55cbe64b66dmr115501e87.21.1754581407295; Thu, 07 Aug 2025 08:43:27 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-33250b6beddsm22293631fa.56.2025.08.07.08.43.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2025 08:43:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <86h5yjp2j3.fsf@gnu.org> Date: Thu, 7 Aug 2025 17:43:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 7 aug. 2025 kl. 17.36 skrev Eli Zaretskii : > If we have the position, can we have the cake and eat it, too? Would > it be possible to call some function in the case of an error that > would calculate the line and column from the position, and include > that in the error data? That way, the performance will suffer only > when there is an error to report. It would be completely useless busy-work in practice. Even if disabled = by default, it's programming work done for something that makes nobody = happy. Let's put our effort where it counts instead. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 12:18:05 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 16:18:05 +0000 Received: from localhost ([127.0.0.1]:35661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk3Jd-0008CA-91 for submit@debbugs.gnu.org; Thu, 07 Aug 2025 12:18:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53484) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk3JS-0008BR-Fw for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 12:18:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uk3JL-0003bK-7V; Thu, 07 Aug 2025 12:17:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=22mWa4ZrODtDr0wCVVlrJZhsrcnpnSymiScro9Nv9tM=; b=b0kTqg6FGqDXrDlcgZ+8 hoMkacSM8COtQ3McvcM2pD9lstYSvcJx9eHgmk2u19PHfDuBg1NKUfPETdaM4tYe60/UHrJGoFUN0 pNcMqjwy4xFYQCgAuylkQ+7rDS60S17GAxfpxlHF+91JPxDwadMBFYImfLTjMGLDuxpinxB6yIQcD 21OQvlWmOlS49aeJJYUAzvsjR/SoNHxPCXrZKVAhsSFQNROIRHjME/yzagBTuNBTfVJlQpFsdarO6 2UOgu7HJqHhUoJz4Lt+y0MYsfMlTMoTxqVIzE+z27uq1cH0vLQsAsXe3TrfgFE9hJMMVSdjpZxndb 8NaWc1C9/2Mdow==; Date: Thu, 07 Aug 2025 19:17:44 +0300 Message-Id: <86ectnp0lz.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Thu, 7 Aug 2025 17:43:26 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Thu, 7 Aug 2025 17:43:26 +0200 > Cc: 79192@debbugs.gnu.org > > 7 aug. 2025 kl. 17.36 skrev Eli Zaretskii : > > > If we have the position, can we have the cake and eat it, too? Would > > it be possible to call some function in the case of an error that > > would calculate the line and column from the position, and include > > that in the error data? That way, the performance will suffer only > > when there is an error to report. > > It would be completely useless busy-work in practice. Even if disabled by default, it's programming work done for something that makes nobody happy. Let's put our effort where it counts instead. Sorry, I don't follow. How is providing helpful data about the locus of an error "useless"? From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 12:32:52 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 16:32:52 +0000 Received: from localhost ([127.0.0.1]:35683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk3Xw-0000Uf-3L for submit@debbugs.gnu.org; Thu, 07 Aug 2025 12:32:52 -0400 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]:59405) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uk3Xn-0000UF-Em for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 12:32:48 -0400 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-55b82db8fd4so1336675e87.2 for <79192@debbugs.gnu.org>; Thu, 07 Aug 2025 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754584356; x=1755189156; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=lk8cCx4iZ06Ns0GTbTYwjwOWURTVsZAjhZhEovhNwSg=; b=PSg5ZHp9rsQ/1pw/6SAa9Drlem7tIxqvCCa/+ssWtqMpn0B5NHnknQ6ZwQf0WDM2vG hR0bhTbfQU1RLVIJvM05jK5pUYKMq+GYH/1h9HyU6BtpXdlVQdDp9R1SjhVtZkKEq5l1 oEaLKSJwg8rDEnWRxQSnhXUjr1Q+CJ2b53/gpYUTUIRjv5ZyzqpRjkhrQYYKW6VwwmiE MJ042wA4dq0ihVgjFSpBAXjqL+npGzaQxo/j+o5FwABk/WEzr42t7fKhYTtE111aA/jx OBjyVYg6EONASfnDRBl1iYByp5ymbK1utMWglVZ2PDa0KlipmVpSknQouIOK+q1FMxNu tKTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754584356; x=1755189156; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lk8cCx4iZ06Ns0GTbTYwjwOWURTVsZAjhZhEovhNwSg=; b=fakim6tUFQostgLt2UHNEQqXe7zcbXAO7IYy9oyTWkEfoKoAraoWoAVTgdqqzppT51 V2M1uFqVFMw0gqzyoqFnxysxAhslS3Q/USk9cPtB4QzQ1EzZ3zJrV0pgEpoaoQcHF2Lp Vz0jP5QJf6tpT68m7gy77wTi98U1tucw7M419ZFfA0mK9wwSIii371KYr6PLHCkVx/4J B8Yp4kb6BtbbkAyIEzX2t+xgGEDRrZJ6WPoR20uqj6ffDNQAzeEqhekuncfuGeZKhZGd YvAbJu6p4BiHsb0+FeDxFjz5ggw5gOjrB7p6mQGNm/yFxQEJI3LkAVPsxCpbDIs5SNvZ 5/CA== X-Gm-Message-State: AOJu0Yz45f0Ie00dZZnzbFVv7uS7CcaHG0KUyz/xvOUhncaTDVN21dQ8 DgGahjkcqo7LQHTmq6Mx5+Q9DcIt7Z9+r5/FHdj9kumyDihASr/503Nc X-Gm-Gg: ASbGnctQLUWZ/z5PEMNBxk2iJzol0e2SV0Hp3rOtBJg7f3hAxbrrUbsd3JRMT3mHKD5 ViigNZWCz/AlWsuwHVcIGUDK8DVvt0MLruEQ8SOb1FRYXdEEDJo7AQSKjKW5bOoH0rGU6b8/ddf DZ2YJmc8UdAmFA2sDa14GUq/evQ7lTRW86NKKJlpZdHrYxDbKsqaPJTunmgXhnuPb2B55YHqZLk VhmhVScwDQbSmwbERbPeLkVGIFDW6cZ908hLIUI/OOfmnGdTk88eSscgk+nLvM7fQEcTzmKLhU0 gRGOBfVmBolvR37c8eaokKh94repJCoCoZSbwbQcAQLm2goFJsuDxYg4K/vvIY/vMhLMGDRmu9o Ogl8GQzj0Uxr/49wm+SiIx6oPalniHm7+1UUUoqJdv4VCEeG5I+Z3pM+QXU6/Vedmt933Z/jACg yeYBFGRoHaa1e/ X-Google-Smtp-Source: AGHT+IE9YuUndAST7382PisS4x29sfP0HkUurvhBrkxt/YXsHD6tHSUyv845TD/NYRxQHkzPdQlOXw== X-Received: by 2002:a05:6512:239b:b0:553:32f3:7ec4 with SMTP id 2adb3069b0e04-55caf5b7959mr2030274e87.29.1754584356025; Thu, 07 Aug 2025 09:32:36 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55b8898bde5sm2734404e87.3.2025.08.07.09.32.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Aug 2025 09:32:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <86ectnp0lz.fsf@gnu.org> Date: Thu, 7 Aug 2025 18:32:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 7 aug. 2025 kl. 18.17 skrev Eli Zaretskii : > How is providing helpful data about the locus > of an error "useless"? Sorry, I didn't intend to sound facetious. What I meant is that the line = and column are not likely to help current or future users in any = significant way: - If anyone would need the point of error, it would almost certainly be = as a position, not line and column. - In the unlikely case that the line and column would be called for, = they can easily be computed by the user. - That computation would be done in Lisp, which is easier; ours would = have to be in C. - Line and column aren't universally well-defined (start at 0 or 1? How = are columns defined? Tabs? Multibyte chars? Combining chars?). The user = is better-placed to use a definition that suits the requirements. - But so far, nobody seems to have a need the point of error in the = first place. Therefore it very much looks like gold-plating. In other words, we'd = give a mistake in the first implementation an unwarranted life extension = when we had a chance to drop it without consequences. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 13:15:40 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 17:15:40 +0000 Received: from localhost ([127.0.0.1]:35768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk4DL-0002Xu-I4 for submit@debbugs.gnu.org; Thu, 07 Aug 2025 13:15:40 -0400 Received: from mail-vs1-xe36.google.com ([2607:f8b0:4864:20::e36]:55572) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uk4DJ-0002Xf-Rb for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 13:15:38 -0400 Received: by mail-vs1-xe36.google.com with SMTP id ada2fe7eead31-4fc05400905so424583137.3 for <79192@debbugs.gnu.org>; Thu, 07 Aug 2025 10:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754586932; x=1755191732; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vdM4cnntJXSgGnjyA58ORVptZoXEjIcr44xzA4Wn6Zg=; b=JLhQY+7J7FnHX7dLaAGPoZ7EU8VU4jhO3eN9JjHS/xggn6Jcf5Uz2hhWyrkqcqRIe9 t86BhZmcbgq4q78joYZFYXMstnnJoniXzMPQyTSXOj+d6SpyTpL+m7vmg4beb4Kimcw2 YoNOCXeDFJu/qQ8gL9nV3ypgfVHpxaEXeOTIzGhpZwoLeGXxO9nwuyQXM/LLmXOBF5ow l6E2EcrnF6qHPVUsDF/WAbR+UI7C799csA/VwpWJUphUWu7cFOR9JS0H/iiEOLZPFHXU j3FEngc1/C2yr9eqXjka0t9gFkdmQ7exxVGj7u1owe0Gqc5Xhh1u72KbSVee40vL9774 NSig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754586932; x=1755191732; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vdM4cnntJXSgGnjyA58ORVptZoXEjIcr44xzA4Wn6Zg=; b=ANCMKCzHknV3kSbaFePASdnGTtcG6iBUOp+vX/zvR5MObAgfWzXx50ilSsU9oh3r6r FSXY3PDBMxN+lOdYbz0bPkyhWP+uedZicz6Zp++GfzzzBmcMm9p7hIHeQ/RDfohKsnxm Soump0AmiMpB2GqvXyO27q7doSV3PB/OMy/VfjSxc0lF2o5fDpD0ByrbqvJnTWSHimqf FBpcFLFCoYF6xsZFB4fUhRSfd0g/qodkxuRs5o5BhPeG+Vgdqv3Jt7kzGEXNTX4FJFze 3WotpNoPyKTElTMZg6LYgmXoPz8oxiJE/YHvNuMtvx2cCt7n4+84Ko/TUxnd2YZQGoP7 UoDQ== X-Forwarded-Encrypted: i=1; AJvYcCULFIvjiqbxKfWb8uCS4ScgGH+AxR1wOu8CBwxKYwYqZjbxdrHtUiuUPOW2XBVXDDBW6x58IA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwL3quF+0jYsof26xfZ/ExpJk6SDcSV0/FHuFW1IXlT3FeANxzD IVtO+VvD/59NFlkvcNxJglZYg/49IHkAauxNV2PqLaA9ilyddVRYT1mAEnsmFcA8XXtPYOMU3CB FdcF+a1iewlw+YCBmJidGyZw6bOeyJcM= X-Gm-Gg: ASbGnctPEJpioAL3l5uJsuOr5RdmLIiEHmk+ePm+gerJ/+/1tT4oITghq9WSj3swF74 YLD8SXbOhZ+UElSBuuIeDq6F4X2a1uIhI2wSFJ9Gi4wIq4qaEbSq5mTgZxxyre+yets7Lf/KaGd xzMzbNbxhqABg1mKgjkiEOaMNW+LxPfFRkGb/roWLgJen/NBT1+s/+Et4q4FJx8WzcGeJ6yAtqd uUDc+XeEQ== X-Google-Smtp-Source: AGHT+IFR1uaQFVzDDYN3JkV//wALfTQM2hs33lZkJlqpkBaLedte2S/NsaVW8pdYfC3UMO8era2BGzwzeBJU3JxZ19g= X-Received: by 2002:a05:6102:3050:b0:4fb:372d:6d70 with SMTP id ada2fe7eead31-50373d14ademr4394589137.26.1754586931616; Thu, 07 Aug 2025 10:15:31 -0700 (PDT) MIME-Version: 1.0 References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> In-Reply-To: <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> From: =?UTF-8?Q?St=C3=A9phane_Marks?= Date: Thu, 7 Aug 2025 13:15:18 -0400 X-Gm-Features: Ac12FXxrOcsIPW25gqYnqN9yQBMO93lu1g16sWOE5jHMY1TZACz2ECO7K_zMq5I Message-ID: Subject: Re: bug#79192: json parsing error position reform To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: multipart/alternative; boundary="000000000000c962ab063bc99a3c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: Eli Zaretskii , 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000c962ab063bc99a3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 7, 2025 at 12:33=E2=80=AFPM Mattias Engdeg=C3=A5rd < mattias.engdegard@gmail.com> wrote: > 7 aug. 2025 kl. 18.17 skrev Eli Zaretskii : > > > How is providing helpful data about the locus > > of an error "useless"? > > Sorry, I didn't intend to sound facetious. What I meant is that the line > and column are not likely to help current or future users in any > significant way: > > - If anyone would need the point of error, it would almost certainly be a= s > a position, not line and column. > - In the unlikely case that the line and column would be called for, they > can easily be computed by the user. > - That computation would be done in Lisp, which is easier; ours would hav= e > to be in C. > - Line and column aren't universally well-defined (start at 0 or 1? How > are columns defined? Tabs? Multibyte chars? Combining chars?). The user i= s > better-placed to use a definition that suits the requirements. > - But so far, nobody seems to have a need the point of error in the first > place. > > Therefore it very much looks like gold-plating. In other words, we'd give > a mistake in the first implementation an unwarranted life extension when = we > had a chance to drop it without consequences. > Most of the json I deal with (not in Emacs, though, or yet) is "minified" and has no newlines. The position would be all I could reasonably use for minified json as the line number would always be 1 and the column number would, I'd hope, equal the position of an error. --000000000000c962ab063bc99a3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Thu, Aug 7, 2025 at 12:33=E2=80=AFPM Mattias Engdeg=C3=A5rd <mattias.engdegard@gmail.com>= wrote:
=
7 aug. 2025 kl. 18.17 skr= ev Eli Zaretskii <eliz= @gnu.org>:

> How is providing helpful data about the locus
> of an error "useless"?

Sorry, I didn't intend to sound facetious. What I meant is that the lin= e and column are not likely to help current or future users in any signific= ant way:

- If anyone would need the point of error, it would almost certainly be as = a position, not line and column.
- In the unlikely case that the line and column would be called for, they c= an easily be computed by the user.
- That computation would be done in Lisp, which is easier; ours would have = to be in C.
- Line and column aren't universally well-defined (start at 0 or 1? How= are columns defined? Tabs? Multibyte chars? Combining chars?). The user is= better-placed to use a definition that suits the requirements.
- But so far, nobody seems to have a need the point of error in the first p= lace.

Therefore it very much looks like gold-plating. In other words, we'd gi= ve a mistake in the first implementation an unwarranted life extension when= we had a chance to drop it without consequences.

=
Most of = the json I deal with (not in Emacs, though, or yet) is "minified"= and has no newlines.=C2=A0 The position would be all I could reasonably us= e for minified json as the line number would always be 1 and the column num= ber would, I'd hope, equal the position of an error.
--000000000000c962ab063bc99a3c-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 14:23:09 2025 Received: (at 79192) by debbugs.gnu.org; 7 Aug 2025 18:23:09 +0000 Received: from localhost ([127.0.0.1]:35889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uk5Gf-0005fQ-2U for submit@debbugs.gnu.org; Thu, 07 Aug 2025 14:23:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40796) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uk5Gc-0005ef-GL for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 14:23:07 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uk5GX-0004Fg-60; Thu, 07 Aug 2025 14:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=8FHeWnoM6b1OsDkRZIdcYWzKXEQk1b5EtxzbwmGv3gg=; b=glKD99VD8A95Z+OJ0PFs E33sioVj3XjA8UcT061rPWKBI56PJhm/npEKD/FK1Pz9cSSz2EQi3SoRo+LrpsFBBQRq4OS+HoSB0 pgGazWcqj3vHZHoRhW5+l1JN1YkUEFqlmzUETMEWxFAD0sl4PYeCr7yUn9VysEEZWxpYp1Of+EMqR 5CUF8+HDiV85ZIDeekSbbCz1PIkEvmtnlfpVEj9z5DVXqSmISSgcSRu3qGQEaEaKa9g3Hf3Abm/Mx KagtRExtLvctfBdabwCxHwTPvLJiVjOkBJEoVtxSNcC1f8rp0kiPdvEKaFtOr0jM8CQC369HjSpeI /KeJqsAGJRHgLA==; Date: Thu, 07 Aug 2025 21:22:46 +0300 Message-Id: <86a54boutl.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Thu, 7 Aug 2025 18:32:34 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Thu, 7 Aug 2025 18:32:34 +0200 > Cc: 79192@debbugs.gnu.org > > 7 aug. 2025 kl. 18.17 skrev Eli Zaretskii : > > > How is providing helpful data about the locus > > of an error "useless"? > > Sorry, I didn't intend to sound facetious. What I meant is that the line and column are not likely to help current or future users in any significant way: > > - If anyone would need the point of error, it would almost certainly be as a position, not line and column. > - In the unlikely case that the line and column would be called for, they can easily be computed by the user. > - That computation would be done in Lisp, which is easier; ours would have to be in C. > - Line and column aren't universally well-defined (start at 0 or 1? How are columns defined? Tabs? Multibyte chars? Combining chars?). The user is better-placed to use a definition that suits the requirements. > - But so far, nobody seems to have a need the point of error in the first place. > > Therefore it very much looks like gold-plating. In other words, we'd give a mistake in the first implementation an unwarranted life extension when we had a chance to drop it without consequences. Every tool that reports errors or hits shows line numbers, and sometimes also column numbers. So it looks like a reasonable thing to expect. Whether they are zero-based or 1-based we could decide by looking at what other tools do (I think 1-based), but that's not the important part. As for calculating lines and columns, I indeed had in mind a call to some Lisp function, which is done only when we are about to signal an error. We don't have to do that in C. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 07 20:43:50 2025 Received: (at 79192) by debbugs.gnu.org; 8 Aug 2025 00:43:50 +0000 Received: from localhost ([127.0.0.1]:36348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukBD3-00066t-PK for submit@debbugs.gnu.org; Thu, 07 Aug 2025 20:43:50 -0400 Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144]:51973) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukBCy-00066O-7s for 79192@debbugs.gnu.org; Thu, 07 Aug 2025 20:43:47 -0400 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfout.stl.internal (Postfix) with ESMTP id 4127C1D00108; Thu, 7 Aug 2025 20:43:38 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Thu, 07 Aug 2025 20:43:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1754613818; x=1754700218; bh=d6Q0FJnmxRL1Qo0AmDF1ftL5TtoplYnZwY3/o9pvrAs=; b= srIxuGyNjSEwBY+ocLy3gT3h+BVoZjNeDNYVVigNSZgmSm9H7+tO2m70ZEmVSJti 3gsfBBrOLsN8aRsNCoGjYMLm1GPGxRyujC62I80JBkg88rgSicVGIiUw2lzhWFpG erW72iHG9q7BN0kJ8l9w7H/CkYbSeDMKeE7+3pmurewbSoRSErEEk/7urPQAgIGQ KkB2nj7e7zPOFs7fLy+IQisoRieNdit9i9kc56VyKPHaKc+p2lUP7ALsX8B5363z h7PZ6xo22r955d3BdzeiW8Jf3312fielTAK+qpN0kggGwEN6VoCq2LO/aLe7wT4b 5+a9wk7gIeI46q81ATe3UA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1754613818; x=1754700218; bh=d 6Q0FJnmxRL1Qo0AmDF1ftL5TtoplYnZwY3/o9pvrAs=; b=OgEn/RFhS0+TxXxpv AXTSD/gT8sNTNP+QkKfmzdhtrcCEAtvRMfwNkOMTT08MiTk9ji9/fEanfAdv6msf Gb1Isqs6kodAa13nM4eYZRNQxYD9bfLrRMuxlG47DiPKs1XUo6HgJtLvogAQfTcr WXRzsFVinmM+D59GS00o3t+UtmusLk2k4wYakIoYDzJ9jIh5pGMabZAI+MNjTzM+ 7nQTc0t72/vSV+drmAVxzoz6PudigrzXB+8Yk2cOAMh+EJAvmKoNIk55nGJSyVS1 gTxaxcNrvXSbT6v//5Lu6rFSq1wx/UqyL/tGbeW0M9XQNe0JO4TfUQWPdWGtVf2N ouG7Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduvddvgedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhmihhtrhih ucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrh hnpeegueegteffuddvjeevvdelleeitdeftdduhfeffeffjedukeevjedvfeffgfevgeen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhith hrhiesghhuthhovhdruggvvhdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphho uhhtpdhrtghpthhtohepmhgrthhtihgrshdrvghnghguvghgrghrugesghhmrghilhdrtg homhdprhgtphhtthhopeejleduledvseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 7 Aug 2025 20:43:36 -0400 (EDT) Message-ID: Date: Fri, 8 Aug 2025 03:43:35 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79192: json parsing error position reform To: =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= , 79192@debbugs.gnu.org References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79192 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 07/08/2025 18:19, Mattias Engdegård wrote: > (2) JSON parse errors aren't expected to occur during normal operation. > (3) From what I can tell, nobody uses the position information of the json-error signal at all. More than that: none of the packages I have installed (at least) even handle that error. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 09 10:08:29 2025 Received: (at 79192) by debbugs.gnu.org; 9 Aug 2025 14:08:29 +0000 Received: from localhost ([127.0.0.1]:42627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukkFI-000853-Sn for submit@debbugs.gnu.org; Sat, 09 Aug 2025 10:08:29 -0400 Received: from mail-lf1-x12c.google.com ([2a00:1450:4864:20::12c]:60458) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ukkFF-00084i-Hm for 79192@debbugs.gnu.org; Sat, 09 Aug 2025 10:08:26 -0400 Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-55b827aba01so2777433e87.0 for <79192@debbugs.gnu.org>; Sat, 09 Aug 2025 07:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754748499; x=1755353299; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=FYs/l7WlLAYqjdYSeuU7JdNguKGepFdWAoS//gELx9w=; b=C/JbkyABwXmc8qPPA/fF/ni4K07E2IAAgIDU5RkQofKyyvEGizRGc9F2HY+EBCxYsq c9LiX2BBK5V97GwXNlat5RqF6VMHIBWAo24+Kud6ZFOAWAqWCuF/GdRrRiFbuzlnt7qe VL2k1iWdytf88kwjHVcpmAy+wzxb+/O+a47iBdJ+PnwyCcK1iFI0yaKeHw5u5oYt/qXF MQondEPSNx3H+a3+UfySpvMGqkIceLxEHRbmJtzjiI52syLndmb8tsistt6cFoZBlxGj RxyXODg0BlaoZsOUZWSMrTDUbkhEvEj/pKZj/Mg9IcJUdNljDsP6y1csJP3OHkHZ6cDc zh8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754748499; x=1755353299; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FYs/l7WlLAYqjdYSeuU7JdNguKGepFdWAoS//gELx9w=; b=KWwma+HkeBLV2Z+Zv4qJZ1DeB0ImnEoFA/kunJlbvvpRuZA3V9//OPkX4nhQz72gRi +zkxtGhjdp/EzE+8lyhwsos0YugSnvB/9GkzuHqMQxdZ9xY51wI+rnFqUVBGeft/p4Nd mzvSJRuuQXkF+xxdUJjDdVfW076niK8TP+umoSaE0T3pdfP001v/KS3R8NeuQHtuqgpf G7sdZL68K129wIsICl5iXVW1BTdd+tu/4vZciDmmKfMbASHQLb5fwcVTCbFaFX0mEjo2 jzQ/dCObM8/XUYM97MtdT6dAaXQgWZcuNPfuSPkeoAVsabrwnMXfERlbRdpGW0SSS9jK VR3g== X-Gm-Message-State: AOJu0YzddeeXe/ZR9JQDta/1CWrGcf9321IkXANgZxomQo2cI8tdPYpH vKF4bycBPePx91/7nmGTywlBoVUTpx7H1R5LIh8ALcmH8Lduwu5k3op3 X-Gm-Gg: ASbGncu5VUM7Cabz/VTe2ipvcPgIQ5uE5rOKyjwEMXhAuiUxcPx0QmaUU/q+Gf4+jky IMucLY5KuCzsbtXq05tcywsIC4yGwFZxVVgyv7duAanO5aCQ+JVxsEi0Hhcl+ch+gsr88kaCZL2 ykfIjvw/of+1pIQOeJI78HopMONRJiV7E0ljAGcolI6mkfaaVbG9WO1EREUw+xjxifpUGjw97Dj eHK+pwqZoFMG6rsqV1ScgmbhHuBR1a0LWu/ZMXFJT1YS8VILYG9BcXIdSe94ahpHUmGMEEfZLML Gcjdi5GsLkTD80jZoKL+2C4C1HXh11nmun4j95rC2Qr3YU09V6uQ3bEU+ADeLmLiaLlzDy68cNP jnFWyc21dy2bjCa8s4ExXqQlwbIE5WrxWV55z6h8M5I9jaa4K6USkuJohTEMo3OcOBRlrDvLNsz URRxYvX13rmMmD X-Google-Smtp-Source: AGHT+IHM4epw05gBVIjg59TpurCxqc9KeqN/meZahPmWBEpR+MBmsHfqau7sAg2zA3PaRRg6BI89UA== X-Received: by 2002:a05:6512:230c:b0:55b:827d:e373 with SMTP id 2adb3069b0e04-55cc0099455mr1914611e87.12.1754748498289; Sat, 09 Aug 2025 07:08:18 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55b88caf6d1sm3407569e87.157.2025.08.09.07.08.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Aug 2025 07:08:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <86a54boutl.fsf@gnu.org> Date: Sat, 9 Aug 2025 16:08:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: Dmitry Gutov , Ship Mints , 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 7 aug. 2025 kl. 20.22 skrev Eli Zaretskii : > Every tool that reports errors or hits shows line numbers, and > sometimes also column numbers. So it looks like a reasonable thing to > expect. But the json parser isn't a tool, it's a low-level primitive that can be = used to make tools. Having it produce line and column numbers makes as much sense as doing = that from `re-search-forward`. Or, if you prefer, from one of our two (three?) XML parser APIs. It just = not how APIs are designed. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 09 10:17:17 2025 Received: (at 79192) by debbugs.gnu.org; 9 Aug 2025 14:17:17 +0000 Received: from localhost ([127.0.0.1]:42674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ukkNo-00005i-As for submit@debbugs.gnu.org; Sat, 09 Aug 2025 10:17:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36726) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ukkNd-0008WG-4p for 79192@debbugs.gnu.org; Sat, 09 Aug 2025 10:17:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ukkNX-0001iK-Hw; Sat, 09 Aug 2025 10:16:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=MMb2n7Bm857M6oUjtJflkuwDegh3TTAyxqwo0HBimzs=; b=FquIV7O6kPE3UXggyjZN OQZzqlcIOMlwJOCuKqWtHZmR5oqtHqKDujDVymhDQltg8+UbzdpLVSeQ54uN5Ik+rizGN/2c5G3g+ h1fXZCLLdiTGDXZJ/ixfq4bDAl4KiqMRabblnxgVceQz9EAWjyp8GeAkXD4rwILFnXFYoTal9p5qQ W3Vn5CoW0MnR4UEmMbxfibmizNZwo0JofVoQGq0oXwBbhl7d8cklud7FIL44LN4XAZFTyNlLEW2kg fChe1OLjIyxAffvq9LSfQt+nexr9N/6XIaJjL0J+atoTeC0kjpeQBEx67rkWa/C9puvYv1wf7htpz /JtxyN1FTIFwnA==; Date: Sat, 09 Aug 2025 17:16:56 +0300 Message-Id: <868qjslgvb.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sat, 9 Aug 2025 16:08:12 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: dmitry@gutov.dev, shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Sat, 9 Aug 2025 16:08:12 +0200 > Cc: 79192@debbugs.gnu.org, > Dmitry Gutov , > Ship Mints > > 7 aug. 2025 kl. 20.22 skrev Eli Zaretskii : > > > Every tool that reports errors or hits shows line numbers, and > > sometimes also column numbers. So it looks like a reasonable thing to > > expect. > > But the json parser isn't a tool, it's a low-level primitive that can be used to make tools. > Having it produce line and column numbers makes as much sense as doing that from `re-search-forward`. > Or, if you prefer, from one of our two (three?) XML parser APIs. It just not how APIs are designed. What are the practical problems of calculating the line number only when an error is about to be reported? That shouldn't affect performance, so I don't see why we would be against doing that. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 10 07:50:13 2025 Received: (at 79192) by debbugs.gnu.org; 10 Aug 2025 11:50:13 +0000 Received: from localhost ([127.0.0.1]:44207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ul4Z3-00016b-AP for submit@debbugs.gnu.org; Sun, 10 Aug 2025 07:50:13 -0400 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:60718) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ul4Yy-00010e-Gj for 79192@debbugs.gnu.org; Sun, 10 Aug 2025 07:50:11 -0400 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-555024588b1so3971797e87.1 for <79192@debbugs.gnu.org>; Sun, 10 Aug 2025 04:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754826602; x=1755431402; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=6Y5PTaGTGznxZYfIlqXE9epKuSSRZmTWBIOknj1xv44=; b=X1e8uky17uLIi2RXkR7vY5s/qPJSMu14uA3MHgMQRl3biScSb6jU0EI6SyXennO/YI MFUd+LqoVWJ3+B5kZy2sTZl4bTSEUQljhJmfjAHESJGiGoboJKYaxo0LzoFnoWIp429B S+PaWACc7SRa0OmvJtlhPiUpSPM88Hn9x50xonRpnFwTuj31JF3o/l9a30fpdU36brrM FMzilrh0nsfDb/ou5f/XVOG01NvHWDlQwyWiTGil5isL/tNtB31dhlfDHmx6v5hmkMzT E2eVqXqjQUZX2pTgrLt5YR6c/hlWpZq6afbPEYYWdXN2ZLuSXzpQDY3B7pvh+Ie4WpU0 Fqyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754826602; x=1755431402; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=6Y5PTaGTGznxZYfIlqXE9epKuSSRZmTWBIOknj1xv44=; b=RlrMrcYNdD7gxqoMQd2bkKBjyC6gklGrZTkDiCcAosNmbhMoQ9aM62LDhFFe0tx1Y4 JPmR5/NmT4oeEYgLlgXx0eOibfNdHEv0lkyFdB+H/xH64YIhwBBWxuWb5ObMVpMfFAUF u8us319Ct21z/bG7tMJp6YrwCHVnkb6ucrxQh2xnBY0dEpvYDLMNKKPQlTPufPVt50Z8 bRRgduBu5DA/fM6hs9oi8Kpl8ISFc587Mqe1JQS2D5DKOyNpSjeiq551uetd5TcYGe73 SoakaQb5NEs14iE8k1e7BGDGzS9C+swK/PgbRRdoina79DgDJJoU0a31hHltv094EPu1 dg/Q== X-Gm-Message-State: AOJu0Yx1l3B2A5nD7lrlVCSRWP/2jpILD7PKW8/wxuhlRlTwDG2O1stJ Jy+Z89qsJ9eE1musiHAifHuH0vP/MdyrwMsJukCP839My2vtP54i61uX X-Gm-Gg: ASbGncua8eddn+FDIqxwq6aifnO8XDEspXXt/9jWf6grrqprmU2EVmgMd8ER1dhRjxs dgt95EontizjNFdcx6nnd1NDTLWmXDzDwQTL7MGu7TzLW6Hu33AZGZL1zppk4dmDifKHTMCE8LO RHRuvob2aiI3navVRlz+oA2v/aurBfWbRUCh1liBo9gL/Bo38wQ4K+Ro8b3uTCXpluCI4Fqhtj4 yVG+CKk7hcqCIpNwW6Kqkctkgg88JuJDS1F/pIHVhokhCQxc0sp5Tn3AGKHiifoFSQsol0dkR3A 7yghLhI3OVfz6r1mpO7CfVnwEP/tUwMM8jWcxGMats+p/cvE16EJy8vgKnzIo6921PQ/+F53zV1 /zo/SG6ny8JFyLX5F4EJgqmnwtZWyH7hDAXOvXBQyLq3z6w0buRmQ/McBxMDjmWX58V7lypepQu aOO1i5aqDXa6wK X-Google-Smtp-Source: AGHT+IHux2608+FEtS3EhpQslUrLQk54onQ69JC6S6olMtJqYnqROR7AJSuwFdjwS39K939M/eKF7A== X-Received: by 2002:a05:6512:a95:b0:55b:9595:c7cd with SMTP id 2adb3069b0e04-55cc015d596mr2901731e87.54.1754826601792; Sun, 10 Aug 2025 04:50:01 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55b889a03acsm3779914e87.51.2025.08.10.04.50.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Aug 2025 04:50:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <868qjslgvb.fsf@gnu.org> Date: Sun, 10 Aug 2025 13:50:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: Dmitry Gutov , Ship Mints , 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 9 aug. 2025 kl. 16.16 skrev Eli Zaretskii : > What are the practical problems of calculating the line number only > when an error is about to be reported? That shouldn't affect > performance, so I don't see why we would be against doing that. What are the pressing needs for doing that? Of the callers of the json parser, not all catch its errors = specifically. Of those that do, most(*) do not use the position information. (*) currently 100 % Of those that would use the position information, many wouldn't need = line and column numbers. Want to position the cursor at the point of the parse error? Don't need = line or column. Want to use faces to show what has been successfully parsed and what has = not? Don't need line or column. Want to write a flymake tool that reports the error? Don't need line or = column. We should not compute line and column in the json parser because there's = no need, and it wouldn't be good API design. Adding code willy-nilly = just because it doesn't slow down normal use much isn't good enough a = reason. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 10 08:03:48 2025 Received: (at 79192) by debbugs.gnu.org; 10 Aug 2025 12:03:48 +0000 Received: from localhost ([127.0.0.1]:44260 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ul4mB-0001hl-Ur for submit@debbugs.gnu.org; Sun, 10 Aug 2025 08:03:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ul4m9-0001hW-0e for 79192@debbugs.gnu.org; Sun, 10 Aug 2025 08:03:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ul4m3-000898-MX; Sun, 10 Aug 2025 08:03:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=z23NUx0dgYcUiHzi0Zg6f9JsTogARNUi6dH6eZRc5rk=; b=VY5HfcMKEwPlmLasJtYk /YgF6FjEV1t/HoR6HchL/Zo1vX8rYKuWFRzz2edAbwS2Wlg40T2DfxRalHgeEkhmCRgZmnTba5tSY XIouQLamy1KQ9DnQa3smAJNQxu2AK55+ulOVdeVbjbxqosRxjq1vjS/THH5dsbQW8jJPeCj5qNJfh o03CPsBUcB8r74cznswJ0V9iKTjgxhWgNmhsBEkewR5nxHuJBitKWvjYDAvmZSki2bWy/q10JWnS1 nSXN56oKJ+Rh+OynX0YvZarvCquOrvblBdn6GxjePJTn+Sn42iyje4W9y5yqFojNiFQrJqkqzEK20 Oxgd6hj70ivOiA==; Date: Sun, 10 Aug 2025 15:03:34 +0300 Message-Id: <86ectjjsdl.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sun, 10 Aug 2025 13:50:00 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: dmitry@gutov.dev, shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Sun, 10 Aug 2025 13:50:00 +0200 > Cc: 79192@debbugs.gnu.org, > Dmitry Gutov , > Ship Mints > > 9 aug. 2025 kl. 16.16 skrev Eli Zaretskii : > > > What are the practical problems of calculating the line number only > > when an error is about to be reported? That shouldn't affect > > performance, so I don't see why we would be against doing that. > > What are the pressing needs for doing that? That we produce this information now. Removing it would be a breaking change, and I'd like to avoid that. > Of the callers of the json parser, not all catch its errors specifically. > > Of those that do, most(*) do not use the position information. > (*) currently 100 % > > Of those that would use the position information, many wouldn't need line and column numbers. > > Want to position the cursor at the point of the parse error? Don't need line or column. > Want to use faces to show what has been successfully parsed and what has not? Don't need line or column. > Want to write a flymake tool that reports the error? Don't need line or column. > > We should not compute line and column in the json parser because there's no need, and it wouldn't be good API design. Adding code willy-nilly just because it doesn't slow down normal use much isn't good enough a reason. I'm against incompatible changes if we can avoid that. Our abilities to be sure that no one uses some feature are very limited and fail time and again. So if we can keep this feature without the performance hit, I'd very much prefer it. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 08:22:14 2025 Received: (at 79192) by debbugs.gnu.org; 11 Aug 2025 12:22:14 +0000 Received: from localhost ([127.0.0.1]:47429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulRXa-0003Qc-3f for submit@debbugs.gnu.org; Mon, 11 Aug 2025 08:22:14 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:52630) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ulRXW-0003QI-JX for 79192@debbugs.gnu.org; Mon, 11 Aug 2025 08:22:11 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55b8a0f36fcso4603614e87.1 for <79192@debbugs.gnu.org>; Mon, 11 Aug 2025 05:22:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754914923; x=1755519723; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=EoGicfgzrqeYu1vf5W9JF3WFUjkww/IMzQscGJ5jyKI=; b=IB6ZMg+kKjghgiYtTzos2a20u0ONetkHnnp44EqOiPyRV04CAMy7weHMbn7T7CJXbk EK2vqFWYo79AexvB6fNc6yHESg1Vd/DJ3czZomd0PC8zo/FDwoSfpuQ3SPNC0ULwb/dM 8jQO5E9b4tptta0eXgTHmXOteDdHd2o7lBEK/iI90uZj6gpwA9862HKIQIod4JXKEP75 iIcGethB9lJqDVfmBiXklzfo9rLqoPy91bWVfAsiew2sa/wz8lsA0stwAkA4dQglabEg 1+G6ShhcDIbJEXmqrwaaIZr/G45dJxcQi3gcGV1oWUoIAt8YvITiKsDmAx9gg+ogh/6o FCyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754914923; x=1755519723; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=EoGicfgzrqeYu1vf5W9JF3WFUjkww/IMzQscGJ5jyKI=; b=lUcKOv7lo6Gjm6smF0MD4+PGM2SY9Z6t4WnJtWPQEj4gT8rEGUZGaU2wS1QsP2HUKB XznVseDpdyTeDk6Mr4iohnNcLlnUrev2szm+3MfE3kfqKwbep4yH0TpyKj6icLaQOq0S ImSSPs2irnRjL53kG9tuy2S89WNmkNeYL4bf8tUWBMKg4App5r0ag4K9wkWobPTkFHmt tnbsLttMUrFNBux53G/AHBa5BcbPVy6pILTY9aw1aiaBGf0nUiW+f2LcSlg6eZ1Kaht/ +4Loyq4GgSJlQdBYYeAINZYcGktTu2OcDSonChkT80OER+g7LNglJPwbMpyaZ9iU7ASb F/kg== X-Gm-Message-State: AOJu0YyU46WdhvACcZUmQHNQHqdgQrrWDgVswEhtCujv5QoDibW5PUPb X3w/mwHnf7gQsEVH+95KSbiNvipphkofTp4xWrxL5AhePdxofaK4xent X-Gm-Gg: ASbGnctCTvxHDewKK112nT9MLfyc6O8X4FOtRED+zZuNCfDn4Gt1uxc9lV59v/2pwfI 3OsLRqraNV2JPgNQhdIFnWfGY9OkG/nfQ/70yY/aw2nvJosF9GUch/9Avyxx0aFodSU1yQRZ9BA qsqydy5EF+hMUGM37ajARQW/1O3XTDdLaX0FOK78TxEOX0wVKZShAUE3zOzGTuMigX1KbLMxqXh xX95SKdjNedyLtPq72MhCjqykkm+s10CGA9uRDDeMUgJ2D3uiy3Ik9oEG5+BTJZeMDO601J2M5I csjnfBtc44aUSrfCwKh8DDLAsNM9NDoxHaQUD6E5jrAct5qjl2fL/asbDLOZdnzoXM3MLalvzQj c09mYbLdknbXGrGKUxPo6vta29A1CYAPBMRTll8+3oZjIrHIdERyLButchVKWXxh63ypqBhlrZs tPGRyRkZfFNtMo3zKyPMfTpd4= X-Google-Smtp-Source: AGHT+IG2zBsXKkMkvB8a3hCF8dliGh4fnz8uyxzfHyFegUAYJryk7uDrh+oKJO05zN3eAuyLbJS82Q== X-Received: by 2002:a05:6512:3c89:b0:55b:7fd2:25f0 with SMTP id 2adb3069b0e04-55cc00f2ddcmr3432177e87.31.1754914923027; Mon, 11 Aug 2025 05:22:03 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55b88c987edsm4324981e87.75.2025.08.11.05.22.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Aug 2025 05:22:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <86ectjjsdl.fsf@gnu.org> Date: Mon, 11 Aug 2025 14:22:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> <86ectjjsdl.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: Dmitry Gutov , shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 10 aug. 2025 kl. 14.03 skrev Eli Zaretskii : > I'm against incompatible changes if we can avoid that. Our abilities > to be sure that no one uses some feature are very limited and fail > time and again. So if we can keep this feature without the > performance hit, I'd very much prefer it. Yes, that's clearly a valid concern and I agree with you in principle. = When I started working on this I assumed that I'd have to include the = line and column calculations because they were there before. And while it's theoretically conceivable that there might be a use in a = file on someone's private disk somewhere, the fact that no public use = could be found at all, that it was never documented, and that it had = only been available for a comparatively short time (since the release of = Emacs 30), all taken together makes it very unlikely that anything would = depend on it. So it seems to be an opportunity to fix a mistake before being too late. = I remember asking the original author of the json parser about it at the = time and got the impression that he'd found it useful at some point = while debugging the parser itself, but it really didn't make much sense = and I made a mental note to get rid of it before the release of Emacs = 30. Goes to show how reliable my mental notes can be. As other people pointed out, the primary use of the json parser is to = decode data generated by other programs and these cram together = everything without whitespace for bandwidth efficiency, like our own = json serialiser does. A minor point: the parser also reports the error position (the third = error parameter, after the line and column) in characters even when the = input was a unibyte string or buffer. That doesn't seem right either and = would refer to the wrong position in the string or buffer so I'm fixing = that bug while at it. From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 11 09:40:59 2025 Received: (at 79192) by debbugs.gnu.org; 11 Aug 2025 13:40:59 +0000 Received: from localhost ([127.0.0.1]:47757 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ulSln-0007Ul-CA for submit@debbugs.gnu.org; Mon, 11 Aug 2025 09:40:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40824) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ulSlg-0007UQ-3j for 79192@debbugs.gnu.org; Mon, 11 Aug 2025 09:40:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ulSlZ-0006iF-6f; Mon, 11 Aug 2025 09:40:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pOCzDbkiFoZA84kpXQ3GxDYUJ/+N26PzCwOHVHeeXM4=; b=Z1AeYyO8djdUMIw6/zhb tCbTgZjboy1gu+4egQuMwkNSuxDWv8Wxa5TC0wLJ2DPR55RRt2Yqac6CjbHd4ed7oEq6qHx2c9Fhd 1YsegVpD8UsaywDKiYyGM9tHwQHan0iCjD/k8cqhTLYsKIQn2Q7hb3+8bHFbMqKKXupXPuCYtisSW BChSGsJxE6JkyFH43hwX9yfylgJLWvzKfugg8EVAZxl9JTum2sRaXWjWtngyL9dYNjpq5wvIzX+1O xBaObU40ZEwzpcipIBpOGuvcIsMkpXAfELfpZMYiEgKlB2+BjuOCTgIrd1AYQ8GjjR6KEbPpxRgTJ hJDEsbu9cwGYqQ==; Date: Mon, 11 Aug 2025 16:40:40 +0300 Message-Id: <868qjqasdj.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Mon, 11 Aug 2025 14:22:01 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> <86ectjjsdl.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: dmitry@gutov.dev, shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Mon, 11 Aug 2025 14:22:01 +0200 > Cc: 79192@debbugs.gnu.org, > Dmitry Gutov , > shipmints@gmail.com > > 10 aug. 2025 kl. 14.03 skrev Eli Zaretskii : > > > I'm against incompatible changes if we can avoid that. Our abilities > > to be sure that no one uses some feature are very limited and fail > > time and again. So if we can keep this feature without the > > performance hit, I'd very much prefer it. > > > Yes, that's clearly a valid concern and I agree with you in principle. When I started working on this I assumed that I'd have to include the line and column calculations because they were there before. > > And while it's theoretically conceivable that there might be a use in a file on someone's private disk somewhere, the fact that no public use could be found at all, that it was never documented, and that it had only been available for a comparatively short time (since the release of Emacs 30), all taken together makes it very unlikely that anything would depend on it. > > So it seems to be an opportunity to fix a mistake before being too late. I remember asking the original author of the json parser about it at the time and got the impression that he'd found it useful at some point while debugging the parser itself, but it really didn't make much sense and I made a mental note to get rid of it before the release of Emacs 30. Goes to show how reliable my mental notes can be. > > As other people pointed out, the primary use of the json parser is to decode data generated by other programs and these cram together everything without whitespace for bandwidth efficiency, like our own json serialiser does. > > A minor point: the parser also reports the error position (the third error parameter, after the line and column) in characters even when the input was a unibyte string or buffer. That doesn't seem right either and would refer to the wrong position in the string or buffer so I'm fixing that bug while at it. I hear you, but then counting lines in Lisp is simple, and we have functions ready to do that. So how hard is it to call one of those functions from the parser, when it detects and error and is about to signal? From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 13:53:55 2025 Received: (at 79192) by debbugs.gnu.org; 12 Aug 2025 17:53:55 +0000 Received: from localhost ([127.0.0.1]:54701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ultC7-0000CM-0D for submit@debbugs.gnu.org; Tue, 12 Aug 2025 13:53:55 -0400 Received: from mail-lf1-x132.google.com ([2a00:1450:4864:20::132]:48368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ultC2-0000C5-Qt for 79192@debbugs.gnu.org; Tue, 12 Aug 2025 13:53:51 -0400 Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-55b96b154bdso5417410e87.0 for <79192@debbugs.gnu.org>; Tue, 12 Aug 2025 10:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755021224; x=1755626024; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=3FWRsbdQ1ffZzZ79T+aXi8jYMQCyjGuQszB2bZNnaGs=; b=ATb8p3ecf6cLRiLlvtE5usAawNcjlPMsxMuZwz+kGS2Er5y//KCl1dH4/GYk6PY5h5 eJIMOT1lE9aiQnSIKyHzpkHXi3VYUM8kD2b2PQQetLSn4mcmGgt0L0vrAsLsehA3Bru3 nxWiuLKjRHzXEDjQxESSZVNqtXs1MD6u9TqNCFsgwfmyKWjTNnhb9r5rGWbI8impXgNq APURnP5+6BaHcUytyg5+YhaLY1f94v9mk9rlUd6IOah2ifZ0vuGDGNg0lQXrlFVnTVjq stNPqxTEUVuZLvlqrGlTa7hy0n8X+BP6fZTh1jdyYyd3McHMb/5kUA00yTp34u0rpYZl lE7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755021224; x=1755626024; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3FWRsbdQ1ffZzZ79T+aXi8jYMQCyjGuQszB2bZNnaGs=; b=BIjVmK05aUViP1Uv6GUkSWrZ2HjiW1qvcFB7kdPOK9KVDqslTb9qLc1gaLcJSeEc9j XW8g8mcf+D6FBKwecxWneCJlqsh8FxjoeA/llu1s70STeUpYmW1F0/3pZBIW1fllXyks gaSPAt9mYpiLrNx081Z/SoDAs3YBjPBll0X2zkSIMPbjt+8TzG58mtl81bygBIH/GY4b kCQLppJSuA3Aq5fQPV7nJ/NdUy9l/RnIFU+3o+qDy2bLkPRpjzLWvF3i9Gl5phF8DBa3 /IU03upj0sdg1Z1rSOy7+LdUqgd1WILEuTMYqKsuoOb6lo2NzH9Px4yxLQQzejhIz097 YE3A== X-Gm-Message-State: AOJu0YwR+dRTXjlPVP2hLI61r1Er7cc+UglbkxtOUqUflc17L0LERQ6M GpG+7VdTVVU3QR+1cZbTkW+ER51DgNiJJ0VaCV0ZGH8qa9HoDwYO86bS X-Gm-Gg: ASbGnctGhs2zoooQ2s0NU7CgLKcmHMPAxMFDCQnoNuM8kkXlQwfFtGfgOUt9jXpkfyV +DKck4Txy3z9o76nlxhSN/Pj4XNRn+cWs5XJh4o+6gTMu7wQ+9rMR3bvjx7RRWstubFMaSXezXV yBHDL5Xtr9W82Qv6mzs/DpyDtwvX3b5dUk4GT1qdcG1xHKR2WdB9hSOLYu24sFIOK4XN5M0VR34 vFwMA/5dYs6Og2IFxFsR56iVOdcoIdQPPZnEQA/vpKhJ+utWQwwppr2Y9PMGmVb53+EZpU0l+MM 6Oe5QmEuLJxlmJaifb/eToKcxndh4UgJn84PPvqIjY0M7g0UccF/4+cjhB3ZVvvGhKg9JEsUg1q kb1mxvsDTKywEIjmEp664tz/N/KeLTWKlDbN7qhxcJ4QDoHgw8dKnmLgkdWDIH13NNFKqou3hTl x9kPsfsQpSfKzX X-Google-Smtp-Source: AGHT+IGwwYFgGRKhKK+h98ZTz50o8I0xfvID0x1Y4DrFL5oy5vwevyiBtdBfDsF+nzGye9RAhYgmMA== X-Received: by 2002:a05:6512:39cb:b0:55c:c9d5:d337 with SMTP id 2adb3069b0e04-55ce0390e12mr48142e87.24.1755021223736; Tue, 12 Aug 2025 10:53:43 -0700 (PDT) Received: from smtpclient.apple (c188-150-186-155.bredband.tele2.se. [188.150.186.155]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-55cc750293esm1841374e87.62.2025.08.12.10.53.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Aug 2025 10:53:43 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: Re: bug#79192: json parsing error position reform From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= In-Reply-To: <868qjqasdj.fsf@gnu.org> Date: Tue, 12 Aug 2025 19:53:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> <86ectjjsdl.fsf@gnu.org> <868qjqasdj.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79192 Cc: dmitry@gutov.dev, shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 11 aug. 2025 kl. 15.40 skrev Eli Zaretskii : > I hear you, but then counting lines in Lisp is simple, and we have > functions ready to do that. So how hard is it to call one of those > functions from the parser, when it detects and error and is about to > signal? The user doesn't care what calculations we make. The values are unused. = (And from the user's perspective, undefined.) From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 12 14:13:16 2025 Received: (at 79192) by debbugs.gnu.org; 12 Aug 2025 18:13:16 +0000 Received: from localhost ([127.0.0.1]:54745 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ultUp-0003yn-Tk for submit@debbugs.gnu.org; Tue, 12 Aug 2025 14:13:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43614) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ultUg-0003y9-Gf for 79192@debbugs.gnu.org; Tue, 12 Aug 2025 14:13:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ultUY-0001dr-Pa; Tue, 12 Aug 2025 14:12:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=lBo1B73v15OldAlOKbBeEbmypu+BA0JtEhtpIZjlzxc=; b=KjJaDAl0aUY6XZeGT0E1 nRHVnXUp1n38XKKm9rE2OO81iM0SECI5ezWGi1/hOgpKmUosq31oTVc1B6T/t7y/11m5+epJ+cqn2 qzVAJpAOJidgeWKAddULK7Yt8lFQGEiQpfJ/bXqsLFIS030jC5h1kal/J+stnNxoVrZ9uqKBaNQX8 ZImp69lxkqwT0HjOLUL0L1h/D/UND1Str0C2ZrH1GZVTtPw/luNkMNb+0Yi/MBvHLouFpiFglqq1W Kzm+m2/RGJ1PXtlfR9SDfVYK6LRtQ3UQdR0MQdKE7vu5woAN5NX3oo43XiI4jGwPRxKiIoBwydhIe YsCLFGg9e5RorA==; Date: Tue, 12 Aug 2025 21:12:54 +0300 Message-Id: <867bz89zo9.fsf@gnu.org> From: Eli Zaretskii To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= In-Reply-To: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Tue, 12 Aug 2025 19:53:42 +0200) Subject: Re: bug#79192: json parsing error position reform References: <0CE6434E-E5BE-4066-9C71-85B0AC302D2B@gmail.com> <86h5yjp2j3.fsf@gnu.org> <813EB984-6952-4CA4-9B7B-DC6F084A3631@gmail.com> <86ectnp0lz.fsf@gnu.org> <09F1466E-BE81-4A64-98EB-1F359681CD2D@gmail.com> <86a54boutl.fsf@gnu.org> <6DF8B312-4202-474C-B814-DFED765531E5@gmail.com> <868qjslgvb.fsf@gnu.org> <416D1DFF-D204-4AF0-A005-95FDA53A1373@gmail.com> <86ectjjsdl.fsf@gnu.org> <868qjqasdj.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79192 Cc: dmitry@gutov.dev, shipmints@gmail.com, 79192@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Mattias Engdegård > Date: Tue, 12 Aug 2025 19:53:42 +0200 > Cc: 79192@debbugs.gnu.org, > dmitry@gutov.dev, > shipmints@gmail.com > > 11 aug. 2025 kl. 15.40 skrev Eli Zaretskii : > > > I hear you, but then counting lines in Lisp is simple, and we have > > functions ready to do that. So how hard is it to call one of those > > functions from the parser, when it detects and error and is about to > > signal? > > The user doesn't care what calculations we make. The values are unused. (And from the user's perspective, undefined.) If the values are available, whether to use them or not is up to the callers, I think. It is none of our business if they don't use them.