From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#57712: 29.0.50; bibtex.el: Should `bibtex-parse-entry' handle curly braces inside fields? Date: Tue, 13 Sep 2022 10:34:50 +0800 Message-ID: <87pmg0t31x.fsf@localhost> References: <87k06b26iu.fsf@localhost> <87r10jrgf4.fsf@gnus.org> <87zgf75i32.fsf@gnu.org> <871qsi5wcf.fsf@gnu.org> <87bkrlw4ml.fsf@localhost> <8735cw3dnm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57712@debbugs.gnu.org, Lars Ingebrigtsen To: Roland Winkler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 13 04:35:10 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oXvlW-0000mO-AN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Sep 2022 04:35:10 +0200 Original-Received: from localhost ([::1]:56658 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oXvlV-0005Kl-A1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Sep 2022 22:35:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56678) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oXvlO-0005JM-2R for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2022 22:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59739) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oXvlN-0000gf-Q8 for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2022 22:35:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oXvlN-0003A9-M5 for bug-gnu-emacs@gnu.org; Mon, 12 Sep 2022 22:35:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Sep 2022 02:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57712 X-GNU-PR-Package: emacs Original-Received: via spool by 57712-submit@debbugs.gnu.org id=B57712.166303644912087 (code B ref 57712); Tue, 13 Sep 2022 02:35:01 +0000 Original-Received: (at 57712) by debbugs.gnu.org; 13 Sep 2022 02:34:09 +0000 Original-Received: from localhost ([127.0.0.1]:48438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXvkX-00038s-AL for submit@debbugs.gnu.org; Mon, 12 Sep 2022 22:34:09 -0400 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:35777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oXvkS-00037m-Hr for 57712@debbugs.gnu.org; Mon, 12 Sep 2022 22:34:07 -0400 Original-Received: by mail-pj1-f45.google.com with SMTP id m10-20020a17090a730a00b001fa986fd8eeso14222805pjk.0 for <57712@debbugs.gnu.org>; Mon, 12 Sep 2022 19:34:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date; bh=QJ+Kw706UoavJg61hMfHiEmZSJSgEIfB+X+Nic5UPpo=; b=PTLYaGXcjtWQmxneijVYZZEOlNmuBv+MgTiWGueoj+oDXCFbgx74Ntag4jGfieAqmw ziBvmCnFyYo8NwuosjgEblC8/1D5lZCKJoGY17tJ7YkrI5LdVSROU11OtKkPytd3+3L4 GdEMLoyoVNXF9MxNWAuRMuoT8g9Sl7B8oKIaIK2oq9kMJvxM9CL8O5ETg1ugV+m6XIXy xizeowU/dLwY0pT2fJa5c8yeyOkM3X0csf1BcWG7iUAGbCORl2a7jdkfikYj+aNpTIsU 6bzb1IZG6iMB0a0CbCpq9KX+YdPV3D9HEYLjhwTYeXMUo6hwRUnnvsdBow1PNZzObCN9 Aiuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date; bh=QJ+Kw706UoavJg61hMfHiEmZSJSgEIfB+X+Nic5UPpo=; b=F4sm51V7M3CGfvDmSpX+6pXM5ddXSeNgBmgShfEOPiLMzlZerbnKgxECrBojrzmS/N rxGFw23sPZTdf2YNfa3iSdqgVQjC82U+thRvJ5I6c1Qg8mBufSF1lD3VIChHBE2uShcX wDmRvLEfy9QdpFzKGhgOrrM26TWFNKS4tXWD2mu3fSdH8tA87EBvc3Q0qky8NYvAOLOQ H6DTzzXqb3KsJ0n4zXXbtNESY1Ih8oStYXD5sesXMWFv1WThH8RikW+jZoR8XFXomIOt aOGT+kLrYRUFNCbE/sWQpx1ek2SzG4Bq/BQ4HRaRfXBs4CqcB80sA9t9GO5HAYhlMbC8 s7tw== X-Gm-Message-State: ACgBeo1ma8FQ5zHEuLsi2ilSl/KzplKYH4CCseyhn/EBUwTo/YL2PR1I ckYHg3gfLxoGb7zBURHVSHA= X-Google-Smtp-Source: AA6agR5iSKiDBLOPERpfzcSDTPKSO36XufFnKHseujX1bovSHkxji4CwH2TCrWRZCrhrUDHdvbqhDA== X-Received: by 2002:a17:902:c245:b0:178:3912:f1f7 with SMTP id 5-20020a170902c24500b001783912f1f7mr5954772plg.75.1663036438592; Mon, 12 Sep 2022 19:33:58 -0700 (PDT) Original-Received: from localhost ([2409:8970:a81:48f7:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id u17-20020a170903125100b001780e4e6b65sm6695830plh.114.2022.09.12.19.33.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 19:33:58 -0700 (PDT) In-Reply-To: <8735cw3dnm.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242315 Archived-At: Roland Winkler writes: > On Mon, Sep 12 2022, Ihor Radchenko wrote: >> To clarify, I do not expect bibtex-parse-entry to strip the braces. What >> I'd like to see is _parsing_ braces (say, as sexp) and other special >> BibTeX syntax. At least, as long as appropriate option is passed to >> bibtex-parse-entry. > > Can you give some examples of what you believe bibtex-parse-entry should > do if it had an optional arg CONTENT? What should it return instead of > what it returns without such an arg? Consider the following title: title =3D {{Introduction $3^5$ to Mark\.{o}v Chain {MOnte} Carl= o \LaTeX}}, (bibtex-parse-entry '(symbols braces mathmode latex strings)) will return '("Introduction " (mathmode "$3^5$") " to Mark=C8=AFv Chain " (braces "{MOn= te}") "Carlo" (latex "\LaTeX")) that is 1. Escaped symbols are replaced by their unicode 2. Braces are indicated by (braces "string") 3. LaTeX math is indicated by (mathmode "math string") 4. LaTeX commands are indicated by (latex "command") 5. @strings are replaced appropriately >> bibtex-summary approach might be an option, although it is clearly an >> abuse and begs for future bugs. > > My point is: the meaning of CONTENT may largely depend on what the > caller of bibtex-parse-entry wants to achieve. What appears perfectly > reasonable from your perspective may be meaningless from another > perspective. That's why the autokey machinery comes with lots of > options in terms of user variables, plus the option of letting the user > ignore all of this and define her own function (both for automatically > generating a key and for generating a summary for an entry). -- It's not > a perfect solution. But it has worked well for many years. > > A single arg CONTENT (trying to guess "do what I mean") cannot cover all > this in a satisfactory way. It can, if it is something like a plist. Note that I do not insist that CONTENT value must be the only way to control the function behaviour. Using let-bound variables is another valid option. But all the affecting variables should be documented in the docstring then. --=20 Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92