From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Masatake YAMATO Newsgroups: gmane.emacs.devel Subject: Re: syntax table in minibuffer Date: Thu, 15 Sep 2011 23:18:11 +0900 (JST) Organization: Red Hat Japan, Inc. Message-ID: <20110915.231811.1552679539416327707.yamato@redhat.com> References: <20110915.175649.18849677874018401.yamato@redhat.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1316096314 19765 80.91.229.12 (15 Sep 2011 14:18:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 15 Sep 2011 14:18:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 15 16:18:28 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R4Clk-00080j-Ec for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2011 16:18:24 +0200 Original-Received: from localhost ([::1]:34618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Clj-00083P-Jx for ged-emacs-devel@m.gmane.org; Thu, 15 Sep 2011 10:18:23 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38437) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Clg-000834-4d for emacs-devel@gnu.org; Thu, 15 Sep 2011 10:18:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4Clc-00024O-35 for emacs-devel@gnu.org; Thu, 15 Sep 2011 10:18:20 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:9002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4Clb-00024G-O8 for emacs-devel@gnu.org; Thu, 15 Sep 2011 10:18:16 -0400 Original-Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8FEIFU3022898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Sep 2011 10:18:15 -0400 Original-Received: from localhost (dhcp-193-19.nrt.redhat.com [10.64.193.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8FEIC2O009454; Thu, 15 Sep 2011 10:18:13 -0400 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144059 Archived-At: >>>> I wanted to choose all chars which is defined as punctuation. >>>> I wanted to convert them to symbol. So \M-\C-f and \M-\C-b can >>>> ignore them. Is there any good way for choosing them? >>>> If not, I have to write a function traversing a given syntax table. >>> map-char-table should do the trick. >> Thanks. I rewrote the patch using the function. > >>> BTW, another way to attack the problem is to leave the syntax-table >>> alone, but set forward-sexp-function. >> I have no idea which is better. > > Setting forward-sexp-function lets you change C-M-f in more subtle ways. > E.g. it can still jump from "/usr/^hello world" (where ^ represents > point) to "/usr/hello^ world" like it does now (and/or jump over parens) > while at the same time being able to jump from "/usr^/hello world" to > "/usr/hello world^". It looks over engineering for me. To go to the whitespace M-f and M-b can be used. Anyway I'd like people to try the patch. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9511 Masatake YAMATO >> However, it will be nice that minibuffer can has its own major >> mode. e.g. minibuffer-filename-mode. > > We currently don't use major modes much in the minibuffer. But maybe we > could move in this direction. If so, we'd probably want to create > a minibuffer-completion-mode to use as parent. Not sure how useful it > would be, tho. > > > Stefan >