From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: c-mode pragma and preproc Date: Sat, 11 Jan 2020 11:44:02 +0000 Message-ID: <20200111114402.GA6005@ACM> References: <20191219140738.q5zdmily5ubwnmg3.ref@Ergus> <20191219140738.q5zdmily5ubwnmg3@Ergus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="246356"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 11 12:48:45 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iqFCQ-000enX-Q5 for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jan 2020 12:45:02 +0100 Original-Received: from localhost ([::1]:56818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iqFCP-00029T-Lg for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Jan 2020 06:45:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49782) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iqFBd-0001iQ-DQ for emacs-devel@gnu.org; Sat, 11 Jan 2020 06:44:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iqFBc-0006ER-8d for emacs-devel@gnu.org; Sat, 11 Jan 2020 06:44:13 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:64763 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iqFBY-0005zW-4B for emacs-devel@gnu.org; Sat, 11 Jan 2020 06:44:12 -0500 Original-Received: (qmail 21146 invoked by uid 3782); 11 Jan 2020 11:44:04 -0000 Original-Received: from acm.muc.de (p2E5D56A0.dip0.t-ipconnect.de [46.93.86.160]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Jan 2020 12:44:02 +0100 Original-Received: (qmail 6109 invoked by uid 1000); 11 Jan 2020 11:44:02 -0000 Content-Disposition: inline In-Reply-To: <20191219140738.q5zdmily5ubwnmg3@Ergus> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:244194 Archived-At: Hello, Ergus. Happy New Year! On Thu, Dec 19, 2019 at 15:07:38 +0100, Ergus wrote: > Hi Alan: > Recently I have been noticing that many "modern" programming models > (Open-MP, OmpSs, OpenACC, programming for Intel Xeon Phi) use > extensively the #pragma sentence. > But in general, while the pre-processor sentences are usually in column > zero ([0]), the #pragma, on the other hand, are preferred to be aligned > with text (0). They are more readable that way. OK, here's a few thoughts on this. Just how unusual is this? I mean, is this indentation only for #pragma, or are there other directives which might want to be indented thus? > Is it possible to add a syntactic symbol to distinguish pragmas from > other preprocessor symbols? (actually pragmas are not pre-processor > sentences in general) I don't think the syntactic symbol is the way to go. It seems to be too heavy a mechanism for a relatively minor requirement. The engine part of a solution seems straightforward: we write a function to be placed on the hook c-special-indent-hook that will run as the last thing in indentation. This function will detect #pragma (with or without spaces) and reindent it. Also it will use the abbrev mechanism used by e.g. "else" to get electric indentation after typing a space after pragma. This bit is not difficult, and I've got some preliminary working code. But what is the interface with the user to look like? This indentation clearly has to be optional - but another "minor mode" (like c-electric-flag, toggled by C-c C-l) doesn't feel right. Maybe a function called something like c-toggle-indent-cpp-to-body would be best. But do we want a list of directives which get this indentation, or is it just for #pragma? > I think that the rest of the rules will not change but probably we need > analogs for: cpp-macro and cpp-macro-cont. There may be a need to indent all lines of a multiline #pragma as cpp-macro-cont. Normally, multiline macros (usually #define) just get indented like ordinary code. Maybe this is a bit more complicated. :-( > In general (AFAIK) the pragmas do not create regions inside like a > define... so we don't need that either. Yes. We need to exclude it, though. > Thanks in advance, > Ergus -- Alan Mackenzie (Nuremberg, Germany).