From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: c-mode pragma and preproc Date: Tue, 14 Jan 2020 15:01:10 +0100 Message-ID: <20200114140110.hrfqmrfkffwsknse@Ergus> References: <20191219140738.q5zdmily5ubwnmg3.ref@Ergus> <20191219140738.q5zdmily5ubwnmg3@Ergus> <20200111114402.GA6005@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="197199"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 14 15:03:12 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 1irMmj-000oi5-Q2 for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2020 15:03:10 +0100 Original-Received: from localhost ([::1]:40372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irMmi-0004oi-2Y for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jan 2020 09:03:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53211) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1irMl5-00039Y-0n for emacs-devel@gnu.org; Tue, 14 Jan 2020 09:01:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1irMl0-0001ux-As for emacs-devel@gnu.org; Tue, 14 Jan 2020 09:01:26 -0500 Original-Received: from sonic308-1.consmr.mail.bf2.yahoo.com ([74.6.130.40]:36287) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1irMl0-0001uH-2S for emacs-devel@gnu.org; Tue, 14 Jan 2020 09:01:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1579010478; bh=0inCH9Zkv931EOy1nIIiGFI1ctMcjzNbk5/vGNQ57FI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=pscBJ7hhtFphO4ZrmlHSOZeFebHB24YcBkxpGRsKZsBZ5XaSKQYDowG5oHNdvdrUA3CZPhGYiAOlTFpYHOUPHAv/ZzfDTy+yMgwAnQms4N8lwt9QK3Nhg5ft1AHh1GzmU4dWGUtMbI2YHyuIQJWwnmO8lg85g/8dZukYKL0GLELXd5VenCXY78Wm9WWZO+/iXPIluXDNIfZrK1BefpNR/+qs30Y4HmMT+SVoilnyxbZYcA0PZHaYwekrD7X65hXDnHL+VlkG6BSNwNUoDc+rwDArsAjRSX/o+cMTVEvs1FSxbb4TQiiSqG39lDfst0+fBBjnkkiBUGUdmseQczTH9w== X-YMail-OSG: kwmPSjMVM1l89sQx_KLHsN_u_cJe1aFAP4GNRAy5c5W_s7hU.q8_9i71XLMcY1w z1aGIi722MGSiL3aGIJ3S56E53abjiiW2Gi64el7LjB4VVX_.otxqRiKn6e1EveyB.BpGd_EB9fd FUUBmwNDpBRysdA7yefM8.4IJNlqoJRVHrjdcdrX4UR9TyEgoTWSKwbKoMYy6DOu37Cvz1oDWVbb Qkqutd7pnMpuuBZDvSxwc0Eo7p7fw2fuoW84bNs5C.e4PkDIJzvXiPe7WwaCBy6a6EHF7BpQvvQy RvFN9NwL4QOPrwIL81KSTU0CvWqmsiMZdE1ofUdb87aFg3erksxwHVCjUc5wDvieXKP55LeNi4iq qk15xzwZd2R1MpGv184TCXeM5UC9vEKZmH7FDZSpRpUZcZgCBWznx9c648l6aReW4ajWBh2j2eya m4tXk5mS2AOhtsn8ET5zjRTBs39.ETWDnSS2ilHDOtqbMZ6fk.yWsUwq4TjNuK9rvERGYeOxyB9V bXWDsK5SMQRoGUVX1xo0u7_ZEEjxCvcY4BH_C4CW0sMe2r2IyfTjc26yGwT4qC2tDV4gTl.zAweC mATSaBrFx28zvjW.X6QJwL.IP3OVqtH7dW68VB_QmkOCa.kcJd.7zjUZV18vP4VsseXSLwlkUjXr EZp5a.SY1ppN1hOKp3WfrEBTEeNfGNiVL5WEejUjwjgtbMkaGH1pJoCvVFZwbaoJH8CYqntETE8K wm6Ogqz0gFzMs5KWYHzR2b.jJBB3k.iDqiCJnTpEozkwm6GK3qPW3FXgoV6_yMz0_ZuF9vTWkKIg T_VSqH96sR63q_Ez9RIEGjXmNKgLYUo18Z0FMTaudZ Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Tue, 14 Jan 2020 14:01:18 +0000 Original-Received: by smtp427.mail.ir2.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c2ed277cc7a83d61d68b973ae3e66c46; Tue, 14 Jan 2020 14:01:12 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20200111114402.GA6005@ACM> X-Mailer: WebService/1.1.14873 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_181) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 74.6.130.40 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:244243 Archived-At: On Sat, Jan 11, 2020 at 11:44:02AM +0000, Alan Mackenzie wrote: Hi Alan: >Hello, Ergus. > >Happy New Year! > Same for you!! >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? > AFAIK only #pragma. >> 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 am in favour of the simplest possible solution. I think that syntactic symbol is actually the simplest one for the final user but you know c-mode better than me. In general as I said before it is only #pragma and I don't understand why it needs to be different from any other syntactic symbol. >> 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. :-( > We can make it as complex as we want. But in general the rest is just the same as with normal macros. Because as the different models will have different keywords we don't need more complexity to be general enough. For example the most general example so far is: #pragma omp parallel shared(salaries1, salaries2) { #pragma omp for reduction(+: salaries1) for (int employee = 0; employee < 25000; employee++) { salaries1 += fetchTheSalary(employee, Co::Company1); } #pragma omp single { std::cout << "Salaries1: " << salaries1 << std::endl; } #pragma omp for reduction(+: salaries1) for (int employee = 0; employee < 25000; employee++) { salaries2 += fetchTheSalary(employee, Co::Company2); } #pragma omp barrier } >> 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). > Best, Ergus