From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Adam Jiang Newsgroups: gmane.emacs.help Subject: Some thoughts about more-smarter-operator Date: Mon, 12 Nov 2012 19:31:40 +0900 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec554d984951e1604ce49ce2e X-Trace: ger.gmane.org 1352716314 9462 80.91.229.3 (12 Nov 2012 10:31:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Nov 2012 10:31:54 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Nov 12 11:32:05 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TXrJE-0004E5-LJ for geh-help-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 11:32:04 +0100 Original-Received: from localhost ([::1]:39002 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXrJ5-0006OX-1o for geh-help-gnu-emacs@m.gmane.org; Mon, 12 Nov 2012 05:31:55 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41993) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXrIv-0006Mu-Ay for help-gnu-emacs@gnu.org; Mon, 12 Nov 2012 05:31:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TXrIs-0002Dn-8h for help-gnu-emacs@gnu.org; Mon, 12 Nov 2012 05:31:45 -0500 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:47530) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TXrIr-0002DY-SK for help-gnu-emacs@gnu.org; Mon, 12 Nov 2012 05:31:42 -0500 Original-Received: by mail-lb0-f169.google.com with SMTP id s4so1287157lbc.0 for ; Mon, 12 Nov 2012 02:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CIlfTi4oB+zz3h0M2S/7eskKWcU16wPCGVAAI8GWTUE=; b=a1UudGuj9yuxGj/4oyP0bf92KM8Rx7nUlceJNBBPv7dBqdd9lbDLaHxSahRoXfwwso MeigdszvsbjpDWYTYNRDtGcBWgafBbHgpge1uXJBh/1ueH/QicdlAGAPNcl1vdxQpEjw e1a08G7qN+Y9PtuKDfrErKB7oXZEIa6pF3v7zlccu90n3b8ye6RBewRYM4epTv5mCTPZ 0z2KP0Xt6Zp4PXcv1NTGZTKZn8fInFdZtV/vnx/X9k8FDJ3WOkBTWBCD1OUtZywCZnIx bdRNNedzHfQO3XQUlfPiImlhFY4kyKo3wZHPF3iDafi2xXocMkNXC94BEWwAat/YVOtF hBsw== Original-Received: by 10.112.49.201 with SMTP id w9mr7605603lbn.100.1352716300655; Mon, 12 Nov 2012 02:31:40 -0800 (PST) Original-Received: by 10.114.24.8 with HTTP; Mon, 12 Nov 2012 02:31:40 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.217.169 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:87651 Archived-At: --bcaec554d984951e1604ce49ce2e Content-Type: text/plain; charset=ISO-8859-1 Hi, I think there are some natural requirements from programmers on the editor to fill up proper whitespaces around operators like typing 'a+b' should be printed to the buffer as 'a + b'. There is an extension called smart-operator.el could do a part of these jobs. However, when I tried it out with my emacs, it failed to me frequently in cc-mode. I have documented these failure to http://www.emacswiki.org/emacs/SmartOperator I also tried to fix these problems. But, finally, my head got shocked when I tried to mimic some code in autopair.el. It seems that smart-operator.el is not smart enough because it doesn't use any syntax analysis result which could be supported by emacs from the beginning. 'smart-operator.el' has to be customized for each languages for its determinative facts are heavily depends on regexs which is proceeding operators. The basic logics in 'smart-operator.el' look like ''''' pseudo code if (in c-buffer) if (looking-back "PATTERN1") insert-whitespaces-as-wrapper OPERATOR else if (looking-back "PATTERN2") insert-whitespaces-only-behind OPERATOR else if (looking-back "PATTERN3") insert-whitespaces-only-front OPERATOR else insert-whitespaces-none OPERATOR Actually, I think the conditions could not rely on PATTERNS but OPERATORS for each major-mode. Then, we can simplify the code for insertion. Here is the situation. There is no way to figure out what is an operator with emacs' syntax-table. (I am not sure about this, if there was, please let me know). However, an operator is an element in the superset of one of the subsets of 'punctuator'. For example, with cc-mode, we have punctuators in syntax-table '*', '%', '/', '+', '-', ... then, operators could be listed in cc-mode would be '*' - binary operator for multiplication '*' - unary operator for get value in a point '*' - delimiter for point declaration '**' - a point to point '****' - a point to point to point to point '*=' - assignment after multiplication etc. If there was a way to describe what kind of strings could be an operator for each major-mode, then, I can introduce some rules based on the assertion to address the same problem that smart-operator wanted to solve, like - remap keybindings to 'puncuators' to a handler - in the handler, if ('puncuator' is in 'operator-list') if (concat last-N-charactors-before-current-position value-of-curent-positon) is in 'operator-list') (back-to-previous position delete-whitespace call 'handler recursively) if 'operator' is unray insert whitespaces before ;;; like char *a; else if 'operator' is binary ;;; '?' ':' could be considered as binary operators insert whitespaces wrapper ;;; like c = a * b; else insert 'puncuator' ;;; backspace, and RET(puncuator) should be solved specially as well. There are some merits which the current smart-operator.el could not provide. - solve the problem by more generic way - easy to be customized; define a list of operators in regex to each major-mode I would like to do this, but, now, the biggest problem for me is that I am not very familiar with elisp. SAD... is anyone interesting in implementing the code in elisp? Do you have any comments on the analysis? Best regards, /Adam --bcaec554d984951e1604ce49ce2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I think there are some natural requirements from programmers on = the editor to fill up proper whitespaces around operators like typing '= a+b' should be printed to the buffer as 'a + b'. There is an ex= tension called smart-operator.el could do a part of these jobs. However, wh= en I tried it out with my emacs, it failed to me frequently in cc-mode. I h= ave documented these failure to

http://www.ema= cswiki.org/emacs/SmartOperator

I also tried to fix these problem= s. But, finally, my head got shocked when I tried to mimic some code in aut= opair.el. It seems that smart-operator.el is not smart enough because it do= esn't use any syntax analysis result which could be supported by emacs = from the beginning. 'smart-operator.el' has to be customized for ea= ch languages for its determinative facts are heavily depends on regexs whic= h is proceeding operators. The basic logics in 'smart-operator.el' = look like

''''' pseudo code
if (in c-buffer)
=A0=A0 if = (looking-back "PATTERN1")
=A0=A0=A0=A0=A0=A0 insert-whitespace= s-as-wrapper OPERATOR
=A0=A0 else if (looking-back "PATTERN2")=
=A0=A0=A0=A0=A0=A0 insert-whitespaces-only-behind OPERATOR
=A0=A0 else if (looking-back "PATTERN3")
=A0=A0=A0=A0=A0=A0 in= sert-whitespaces-only-front OPERATOR
=A0=A0 else
=A0=A0=A0=A0=A0=A0 i= nsert-whitespaces-none OPERATOR

Actually, I think the conditions cou= ld not rely on PATTERNS but OPERATORS for each major-mode. Then, we can sim= plify the code for insertion. Here is the situation.

There is no way to figure out what is an operator with emacs' synta= x-table. (I am not sure about this, if there was, please let me know). Howe= ver, an operator is an element in the superset of one of the subsets of = 9;punctuator'. For example, with cc-mode, we have punctuators in syntax= -table

'*', '%', '/', '+', '-', ...
then, operators could be listed in cc-mode would be

'*'= ; - binary operator for multiplication
'*' - unary operator for = get value in a point
'*' - delimiter for point declaration
'**' - a point to = point
'****' - a point to point to point to point
'*=3D&#= 39; - assignment after multiplication
etc.

If there was a way to = describe what kind of strings could be an operator for each major-mode, the= n, I can introduce some rules based on the assertion to address the same pr= oblem that smart-operator wanted to solve, like

- remap keybindings to 'puncuators' to a handler
- in the ha= ndler,

if ('puncuator' is in 'operator-list')
=A0= =A0=A0 if (concat last-N-charactors-before-current-position value-of-curent= -positon) is in 'operator-list')
=A0=A0=A0 =A0=A0 (back-to-previous position
=A0=A0=A0 =A0=A0=A0 delete-w= hitespace
=A0=A0=A0 =A0=A0=A0 call 'handler recursively)
=A0=A0= =A0 if 'operator' is unray
=A0=A0=A0=A0=A0=A0=A0 insert whitespa= ces before ;;; like char *a;
=A0=A0=A0 else if 'operator' is bin= ary ;;; '?' ':' could be considered as binary operators
=A0=A0=A0=A0=A0=A0=A0 insert whitespaces wrapper ;;; like c =3D a * b;
e= lse
=A0=A0=A0 insert 'puncuator' ;;;

backspace, and RET(p= uncuator) should be solved specially as well.

There are some merits = which the current smart-operator.el could not provide.

- solve the problem by more generic way
- easy to be customized; def= ine a list of operators in regex to each major-mode

I would like to = do this, but, now, the biggest problem for me is that I am not very familia= r with elisp. SAD... is anyone interesting in implementing the code in elis= p? Do you have any comments on the analysis?

Best regards,
/Adam
--bcaec554d984951e1604ce49ce2e--