From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Bielawski, Richard G." Newsgroups: gmane.emacs.devel Subject: RE: 2 character comment starter bug Date: Wed, 23 Mar 2005 18:28:42 -0800 Message-ID: <7D10EFE37E7CBF4288CAFDFAD3C7932C3466E5@msgswbmnmsp04.wellsfargo.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: sea.gmane.org 1111631974 15904 80.91.229.2 (24 Mar 2005 02:39:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2005 02:39:34 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 03:39:34 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DEIFu-0000Ed-1K for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2005 03:39:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DEIRD-00031y-Qq for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2005 21:51:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DEIQS-0002qE-PR for emacs-devel@gnu.org; Wed, 23 Mar 2005 21:50:24 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DEIQP-0002oc-Hh for emacs-devel@gnu.org; Wed, 23 Mar 2005 21:50:22 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DEIQO-0002lS-NY for emacs-devel@gnu.org; Wed, 23 Mar 2005 21:50:20 -0500 Original-Received: from [159.37.7.78] (helo=adred.wellsfargo.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DEI5Z-0004bC-Kx for emacs-devel@gnu.org; Wed, 23 Mar 2005 21:28:50 -0500 Original-Received: from unixm4.wellsfargo.com (unixm4.wellsfargo.com [10.30.2.214]) by adred.wellsfargo.com (8.12.9-20030924/8.12.10) with ESMTP id j2O2SmKg024361 for ; Wed, 23 Mar 2005 19:28:48 -0700 (MST) Original-Received: from unixm4.wellsfargo.com (localhost [127.0.0.1]) by unixm4.wellsfargo.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j2O2SlFt011791 for ; Wed, 23 Mar 2005 20:28:47 -0600 (CST) Original-Received: from pcs0701-010-02s.ent.wfb.bank.corp (pcs0701-010-02s.wellsfargo.com [10.12.104.218]) by unixm4.wellsfargo.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j2O2SkFt011785 for ; Wed, 23 Mar 2005 20:28:46 -0600 (CST) Original-Received: from msgaw55cacah10.wellsfargo.com ([10.12.52.252]) by pcs0701-010-02s.ent.wfb.bank.corp with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Mar 2005 18:28:45 -0800 Original-Received: by msgsw55cacah22.wellsfargo.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Mar 2005 18:32:11 -0800 Original-To: "'Stefan Monnier'" X-Mailer: Internet Mail Service (5.5.2653.19) X-OriginalArrivalTime: 24 Mar 2005 02:28:45.0972 (UTC) FILETIME=[344D3D40:01C53019] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: news.gmane.org gmane.emacs.devel:35080 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:35080 > >> > (modify-syntax-entry ?\= "_ b12" st) ; comment start == > >> > >> Yes, it seems the problem is that your 2-char comment > sequence is made > >> of symbol-chars, so there are cases where the code does > things like "oh, > >> here's a symbol, let's skip it" without checking whether > some of the > >> chars that compose the symbol happen to also be a comment-marker. > >> > >> Does your = char really need to have "symbol" syntax (i.e. "_") or > >> could it have punctuation syntax instead (i.e. ".") ? > > > Punctuation syntax seems to cause all kinds of problems. The = > > character is commonly used as the first character in in > > filenames. > > But does it matter in such a case whether it has punctuation syntax or > symbol syntax? Do you also give symbol syntax to the / > directory separator as well? A / is an illegal character in any part of a filename on this system. In this language / / are most often seen as paired delimiters. > > It's also part of several operators such as := and ':=' and > '=:' which > > would behave quite oddly without proper syntax. > > Traditionally, punctuation syntax has been used specifically > for things like > the above. So, I'd say that punctuation *is* the proper > syntax. If you use > symbol syntax for those chars, things like M-C-f risk skipping over > "foo:=bar" in "foo:=bar + 1", rather than just skipping over "foo". [#set foo [bar]] and [#set foo [#compute bar + 1]] would be required to accomplish the operations your examples seem to describe. If I see ':=' in this language I would almost certainly want it treated as a word. > > > It sounds like you are saying it might be a problem to fix the code. > > Yes: it might take a bit of work; it risks slowing down syntax-based > operations in all buffers; and it could introduce bugs in > other languages > where the current behavior is closer to what we want (after > all, if you > define your language using lex and you say that a symbol can > be [a-z=_]+ > and a comment starter is ==, your lexer will take `foo==' to > be a symbol > and won't see the comment starter in it). In this language == always begins a comment no matter where it is found unless a ~ precedes it. There are no exceptions. > > The current behavior is buggy (it doesn't behave consistently between > things like forward-sexp, backward-sexp, and parse-partial-sexp). > > But before someone can convince me to try and fix these bugs, > they should > first make a good case that the way they setup their > syntax-tables is well > thought out. > If the fact that the problem exists reflects the standard by which `well thought out' is measured you're being a pushover. I suppose, since it's possible for me to work around this problem by using syntactic-keywords to handle the comments I would prefer problems for which there are no workarounds be addressed first. If it will remain this way for any length of time though, I do think it should be documented somewhere. Even if only on a known problems list.