From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Budi Newsgroups: gmane.emacs.help Subject: Re: help-gnu-emacs Digest, Vol 198, Issue 25 Date: Wed, 8 May 2019 18:43:53 +0700 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123132"; mail-complaints-to="usenet@blaine.gmane.org" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed May 08 13:44:22 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOKzm-000Vt7-CZ for geh-help-gnu-emacs@m.gmane.org; Wed, 08 May 2019 13:44:22 +0200 Original-Received: from localhost ([127.0.0.1]:35338 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOKzl-0004Y5-En for geh-help-gnu-emacs@m.gmane.org; Wed, 08 May 2019 07:44:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42592) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOKzO-0004Rt-7b for help-gnu-emacs@gnu.org; Wed, 08 May 2019 07:44:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOKzM-0004MN-BB for help-gnu-emacs@gnu.org; Wed, 08 May 2019 07:43:58 -0400 Original-Received: from mail-it1-x133.google.com ([2607:f8b0:4864:20::133]:54087) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOKzM-0004Lk-5n for help-gnu-emacs@gnu.org; Wed, 08 May 2019 07:43:56 -0400 Original-Received: by mail-it1-x133.google.com with SMTP id l10so3512758iti.3 for ; Wed, 08 May 2019 04:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qqAkf3XmYqiyf5wFsj/YFvdzq7KqJpW4t6FaAxKyEH4=; b=lxK/xqMiMIeZf6u/YalL/V+78DPYuivWMGwLcGlW1MjZiGYRZ7D4X2SsHzExEKPvsm alsZBFVOVrENAKmEl4gGyXHXGLVL0k6PKt1naTebSTNzCybdZDx6Wl8+cWvY783RqKfC SpxHi86D5vSwgMYiQfj6zc8RbVeW3wN5NWbSztVTbvlHs3b84dek/ysN9yOd3VQcUTUW yPGQfjnMq/Z+P9BFK+F9XNbmO1CtPydyK/moix/nEH6pib7C09drvOV/ItqA+eCBtAYi ANw41Lkj7lmcMM/+fzYXxznLujkkeq3B0/yscqCINjUD/LVIP02gKO/g3Ssu5CeLcQgI XBMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qqAkf3XmYqiyf5wFsj/YFvdzq7KqJpW4t6FaAxKyEH4=; b=Sih9yoq4VNfejhOA8/U+2nnJ/ksrecKWmhtF1ys9WJXoBkv81+tzBs3IumlbxUpqpu Hba7ajIZ1qvDs3TZotZDwwJULFkNy6P5BakkhksGXWia5G2SieTn1pK/RSTJoJljZzO8 AFfFGXm0sSLChAgti/EhuEyn0zembfa0jzSB/GJqBALAT6epoxdWnVwALkHfMXgjDILZ MNle+4XbvLVgWHSePT4eDQzNz4Z//X6zBghDp2LHVt9pIdjmUzXpUY+pJ3V3xx8JWOZp mqq0E8winKL0u0sEexmquoLHlPd23771CVimBmRZmXoxxJPXPho9bRVFKt1ixFGTE5B+ J9aw== X-Gm-Message-State: APjAAAXDl1/aKNACy1rM9iBj6kiyh1W/H2dzhIpj9e90lyZG4cnKzy8A ArJpfRPcg++iVlDx+xcZbefi8YE6Fq/chjzcPG3yqYNW X-Google-Smtp-Source: APXvYqyD9gQIuyuLrsCQg6B4mca4rlsvEUlCB2oDeK7jMkJ8M6tgetHI28MNeBLoCVuY8jsF2iR4K9p7ew6IKMC3ES4= X-Received: by 2002:a02:62ce:: with SMTP id d197mr27474486jac.91.1557315833846; Wed, 08 May 2019 04:43:53 -0700 (PDT) Original-Received: by 2002:a02:5b45:0:0:0:0:0 with HTTP; Wed, 8 May 2019 04:43:53 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::133 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.help:120261 Archived-At: How to make emacs always to show point value on strip/bar what workaround to get such if no standard menu exists On 5/7/19, help-gnu-emacs-request@gnu.org wrote: > Send help-gnu-emacs mailing list submissions to > help-gnu-emacs@gnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnu.org/mailman/listinfo/help-gnu-emacs > or, via email, send a message with subject or body 'help' to > help-gnu-emacs-request@gnu.org > > You can reach the person managing the list at > help-gnu-emacs-owner@gnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of help-gnu-emacs digest..." > > > Today's Topics: > > 1. Re: Why is Elisp slow? (Stefan Monnier) > 2. Re: Why is Elisp slow? (???) > 3. Re: Why is Elisp slow? (Stefan Monnier) > 4. Re: Why is Elisp slow? (Ergus) > 5. Re: Why is Elisp slow? (???) > 6. Re: Why is Elisp slow? (Ergus) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 07 May 2019 08:56:24 -0400 > From: Stefan Monnier > To: ??? > Cc: Ergus , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: > Content-Type: text/plain; charset=utf-8 > >>> - Writing wrappers in lisp for all our C functions exposed to Lisp I > > All those are defined with a "DEFUN" macro on the C side. > Whatever change is needed on this side can likely be made largely > mechanically, so I'm not worried. > > Similarly, you'll need to rewrite all the functions/macros like CONSP, > SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those > is important. > >> What I was thinking about using CL to support Elisp is to define a new >> namespace for symbols (which, in CL terms, is a so-called ?package?) >> named ?elisp?. > > As I already mentioned, this already exists: elisp.lisp. > > > Stefan > > > > ------------------------------ > > Message: 2 > Date: Tue, 7 May 2019 22:01:12 +0900 > From: ??? > To: Stefan Monnier > Cc: Ergus , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: <798C9A13-7A2F-4C43-A5D9-6FDE00D647FC@icloud.com> > Content-Type: text/plain; charset=utf-8 > > > >> 2019. 5. 7. ?? 9:56, Stefan Monnier ??: >> >>>> - Writing wrappers in lisp for all our C functions exposed to Lisp I >> >> All those are defined with a "DEFUN" macro on the C side. >> Whatever change is needed on this side can likely be made largely >> mechanically, so I'm not worried. >> >> Similarly, you'll need to rewrite all the functions/macros like CONSP, >> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those >> is important. > > Why would you not use the default CL?s defun, car, cdr, symbol-p, cons-p, > etc, etc? > >>> What I was thinking about using CL to support Elisp is to define a new >>> namespace for symbols (which, in CL terms, is a so-called ?package?) >>> named ?elisp?. >> >> As I already mentioned, this already exists: elisp.lisp. >> >> >> Stefan >> > > > > > ------------------------------ > > Message: 3 > Date: Tue, 07 May 2019 09:04:31 -0400 > From: Stefan Monnier > To: ??? > Cc: Ergus , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: > Content-Type: text/plain; charset=utf-8 > >>> Similarly, you'll need to rewrite all the functions/macros like CONSP, >>> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those >>> is important. >> >> Why would you not use the default CL?s defun, car, cdr, symbol-p, >> cons-p, etc, etc? > > I'm talking the work needed to adapt Emacs's C code, e.g: > > DEFUN ("get-buffer-window", Fget_buffer_window, Sget_buffer_window, 0, > 2, 0, > doc: /* Return a window currently displaying BUFFER-OR-NAME, or > nil if none. > BUFFER-OR-NAME may be a buffer or a buffer name and defaults to > the current buffer. > > The optional argument ALL-FRAMES specifies the frames to consider: > > - t means consider all windows on all existing frames. > > - `visible' means consider all windows on all visible frames. > > - 0 (the number zero) means consider all windows on all visible > and iconified frames. > > - A frame means consider all windows on that frame only. > > Any other value of ALL-FRAMES means consider all windows on the > selected frame and no others. */) > (Lisp_Object buffer_or_name, Lisp_Object all_frames) > { > Lisp_Object buffer; > > if (NILP (buffer_or_name)) > buffer = Fcurrent_buffer (); > else > buffer = Fget_buffer (buffer_or_name); > > if (BUFFERP (buffer)) > return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames); > else > return Qnil; > } > > > -- Stefan > > > > ------------------------------ > > Message: 4 > Date: Tue, 7 May 2019 15:14:42 +0200 > From: Ergus > To: Stefan Monnier > Cc: ??? , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: <20190507131442.7hnyuqpknzldorur@Ergus> > Content-Type: text/plain; charset=utf-8; format=flowed > > On Tue, May 07, 2019 at 09:04:31AM -0400, Stefan Monnier wrote: >>>> Similarly, you'll need to rewrite all the functions/macros like CONSP, >>>> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those >>>> is important. >>> >>> Why would you not use the default CL???s defun, car, cdr, symbol-p, >>> cons-p, etc, etc? >> >>I'm talking the work needed to adapt Emacs's C code, e.g: >> >> DEFUN ("get-buffer-window", Fget_buffer_window, Sget_buffer_window, 0, >> 2, 0, >> doc: /* Return a window currently displaying BUFFER-OR-NAME, or >> nil if none. >> BUFFER-OR-NAME may be a buffer or a buffer name and defaults to >> the current buffer. >> >> The optional argument ALL-FRAMES specifies the frames to consider: >> >> - t means consider all windows on all existing frames. >> >> - `visible' means consider all windows on all visible frames. >> >> - 0 (the number zero) means consider all windows on all visible >> and iconified frames. >> >> - A frame means consider all windows on that frame only. >> >> Any other value of ALL-FRAMES means consider all windows on the >> selected frame and no others. */) >> (Lisp_Object buffer_or_name, Lisp_Object all_frames) >> { >> Lisp_Object buffer; >> >> if (NILP (buffer_or_name)) >> buffer = Fcurrent_buffer (); >> else >> buffer = Fget_buffer (buffer_or_name); >> >> if (BUFFERP (buffer)) >> return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames); >> else >> return Qnil; >> } >> >> >>-- Stefan >> > That's why I was wondering about the C binds and the C types > representations in SBCL more than the lisp part of the implementation. > > > > ------------------------------ > > Message: 5 > Date: Tue, 7 May 2019 22:16:42 +0900 > From: ??? > To: Stefan Monnier > Cc: Ergus , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: <07106E19-C81B-460A-A481-570C7902694D@icloud.com> > Content-Type: text/plain; charset=utf-8 > > Ahh? I now understood what?s the problem. :-( > >> 2019. 5. 7. ?? 10:04, Stefan Monnier ??: >> >>>> Similarly, you'll need to rewrite all the functions/macros like CONSP, >>>> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those >>>> is important. >>> >>> Why would you not use the default CL?s defun, car, cdr, symbol-p, >>> cons-p, etc, etc? >> >> I'm talking the work needed to adapt Emacs's C code, e.g: >> >> DEFUN ("get-buffer-window", Fget_buffer_window, Sget_buffer_window, 0, >> 2, 0, >> doc: /* Return a window currently displaying BUFFER-OR-NAME, or >> nil if none. >> BUFFER-OR-NAME may be a buffer or a buffer name and defaults to >> the current buffer. >> >> The optional argument ALL-FRAMES specifies the frames to consider: >> >> - t means consider all windows on all existing frames. >> >> - `visible' means consider all windows on all visible frames. >> >> - 0 (the number zero) means consider all windows on all visible >> and iconified frames. >> >> - A frame means consider all windows on that frame only. >> >> Any other value of ALL-FRAMES means consider all windows on the >> selected frame and no others. */) >> (Lisp_Object buffer_or_name, Lisp_Object all_frames) >> { >> Lisp_Object buffer; >> >> if (NILP (buffer_or_name)) >> buffer = Fcurrent_buffer (); >> else >> buffer = Fget_buffer (buffer_or_name); >> >> if (BUFFERP (buffer)) >> return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames); >> else >> return Qnil; >> } >> >> >> -- Stefan >> > > > > > ------------------------------ > > Message: 6 > Date: Tue, 7 May 2019 15:40:23 +0200 > From: Ergus > To: ??? > Cc: Stefan Monnier , help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: <20190507134023.kxilippv5vr7wjdv@Ergus> > Content-Type: text/plain; charset=utf-8; format=flowed > > On Tue, May 07, 2019 at 10:16:42PM +0900, ????????? wrote: > > Yes, it is not straight forward, but that's what makes it more > interesting (and useful). > > I still think that provide a plugin for SBCL is the best to do it native > and efficient, but I have zero knowledge about the SBCL infrastructure > for that. But the idea of adding it some C bindings is not > crazy. Specially because all the functions have the same signature. We > just need some documentation about the internal data structure > representations in SBCL. > >>Ahh??? I now understood what???s the problem. :-( >> >>> 2019. 5. 7. ?????? 10:04, Stefan Monnier >>> ??????: >>> >>>>> Similarly, you'll need to rewrite all the functions/macros like CONSP, >>>>> SYMBOLP, FIXNUMP, XCAR, XCDR, make_fixnum, ... Performance of those >>>>> is important. >>>> >>>> Why would you not use the default CL???s defun, car, cdr, symbol-p, >>>> cons-p, etc, etc? >>> >>> I'm talking the work needed to adapt Emacs's C code, e.g: >>> >>> DEFUN ("get-buffer-window", Fget_buffer_window, Sget_buffer_window, 0, >>> 2, 0, >>> doc: /* Return a window currently displaying BUFFER-OR-NAME, or >>> nil if none. >>> BUFFER-OR-NAME may be a buffer or a buffer name and defaults to >>> the current buffer. >>> >>> The optional argument ALL-FRAMES specifies the frames to consider: >>> >>> - t means consider all windows on all existing frames. >>> >>> - `visible' means consider all windows on all visible frames. >>> >>> - 0 (the number zero) means consider all windows on all visible >>> and iconified frames. >>> >>> - A frame means consider all windows on that frame only. >>> >>> Any other value of ALL-FRAMES means consider all windows on the >>> selected frame and no others. */) >>> (Lisp_Object buffer_or_name, Lisp_Object all_frames) >>> { >>> Lisp_Object buffer; >>> >>> if (NILP (buffer_or_name)) >>> buffer = Fcurrent_buffer (); >>> else >>> buffer = Fget_buffer (buffer_or_name); >>> >>> if (BUFFERP (buffer)) >>> return window_loop (GET_BUFFER_WINDOW, buffer, true, all_frames); >>> else >>> return Qnil; >>> } >>> >>> >>> -- Stefan >>> >> >> > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > help-gnu-emacs mailing list > help-gnu-emacs@gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnu-emacs > > > ------------------------------ > > End of help-gnu-emacs Digest, Vol 198, Issue 25 > *********************************************** >