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 28 Date: Thu, 9 May 2019 17:43:29 +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="30772"; 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 Thu May 09 12:44:47 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 1hOgXf-0007sm-80 for geh-help-gnu-emacs@m.gmane.org; Thu, 09 May 2019 12:44:47 +0200 Original-Received: from localhost ([127.0.0.1]:52195 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOgXe-0007RX-7l for geh-help-gnu-emacs@m.gmane.org; Thu, 09 May 2019 06:44:46 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOgWT-0006vb-RV for help-gnu-emacs@gnu.org; Thu, 09 May 2019 06:43:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hOgWR-0007v4-Kh for help-gnu-emacs@gnu.org; Thu, 09 May 2019 06:43:33 -0400 Original-Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]:42536) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hOgWR-0007uF-D4 for help-gnu-emacs@gnu.org; Thu, 09 May 2019 06:43:31 -0400 Original-Received: by mail-io1-xd2c.google.com with SMTP id g16so1217735iom.9 for ; Thu, 09 May 2019 03:43:31 -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=b57Hy2DoqzpUEMwwEGhpg2hh3NTB2wmUlKSa84Zj6tE=; b=lhV8RvDGk/9bAwgDLw/pDQkH1FwDmUftZC6hI6jTdSsYju6apNNO/Ftml07ggtl5WK 7SISN+iDXM2ZKQRdSRY0WSZkF8+4LhJ4Jt6gMpCNe/zjARrbhxVE3i4JzEcbFJSr+32H KM17ew/DwY3AidN77Ai8EUb/J3h76r1N31yhGCIdAdQuHtrvIdfzx/oEZGNnGeXjWgej N5Z0xnAs3JrboLBLbf8T/WdIFrmWtwN1qcUTxnFA8B2pIjMR4n4riyVGBNeR0XDYiZoC Y3uT7CyRzyqq+uVa8GxiEzkdV/Quj+LRPOnToD+/Oy2BKRZsVEYMG8pAJxmVoki7npTc XF2A== 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=b57Hy2DoqzpUEMwwEGhpg2hh3NTB2wmUlKSa84Zj6tE=; b=ZYe/6MA6ypPYCHOOIFNDdPtrM60TUiaWG7ib4YFopgzi1PgSGevMpsY7cmbtUVrgmI OpL6mCTxiQkqU0ZLX0NFBXx/HRfMer4oVyEur5AOkasUKnh8wurGaccbgTkGRHV+J2Xm t3SZFeGpH5dbNjYqlRlVvEqzGuFAIns068V2pztRBRxJGBg5vkPQwPqvmPRXfGamSgVV NGySImrLUniQYZruTOrnGk0riiLoVBXB38NiTzYUtHqplfxCfEQX3LmRj9BX5mcJdERC Glq5/ONtvo6LuyM3Y4fFEfszdXQ+0axlYxU7YFais9mY3ubX2XMwMZcBb1QsCajsicqb fPZg== X-Gm-Message-State: APjAAAUeDKlZK9SFbzMIAPbOF/3IRALEly5NEVH2c0bKyT3wZM4YjNZC nKtkkqKAwqGwqsRCA0xpU6vNNp6NyLLV4lihK4Leh3GA X-Google-Smtp-Source: APXvYqwrqGpMzWDEwFgGey3KuZsxPEQIh0GVZo2AyGcuD9mw7id2gZRv2aaiZqhe77IAwTVZE5SWSk4d+jr1wT2n45g= X-Received: by 2002:a6b:ec0d:: with SMTP id c13mr1954814ioh.163.1557398610062; Thu, 09 May 2019 03:43:30 -0700 (PDT) Original-Received: by 2002:a02:93cd:0:0:0:0:0 with HTTP; Thu, 9 May 2019 03:43:29 -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::d2c 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:120273 Archived-At: Here my .emacs for showing point (add-to-list 'mode-line-position '(pointof (7 (:eval (format "%d" (point))))) 'append) (define-minor-mode pointof "") (pointof t) from tonycubit with a bit concise On 5/9/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: how to show point value on strip/bar (aka modeline) [was: > help-gnu-emacs Digest, Vol 198, Issue 25] (Emanuel Berg) > 2. Re: Question about defcustom and load-history (Mauro Aranda) > 3. Re: help-gnu-emacs Digest, Vol 198, Issue 27 (Budi) > 4. Re: help-gnu-emacs Digest, Vol 198, Issue 27 (Emanuel Berg) > 5. How to clipboard copy emacs help text by user-made > interactive function kill-ring-save (Budi) > 6. Re: How to clipboard copy emacs help text by user-made > interactive function kill-ring-save (Emanuel Berg) > 7. Re: Why is Elisp slow? (Ergus) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 08 May 2019 18:06:40 +0200 > From: Emanuel Berg > To: help-gnu-emacs@gnu.org > Subject: Re: how to show point value on strip/bar (aka modeline) [was: > help-gnu-emacs Digest, Vol 198, Issue 25] > Message-ID: <86sgtpkk1b.fsf@zoho.eu> > Content-Type: text/plain > > tomas wrote: > >> I interpreted OP's "point" als the >> combination of (line/column). > > Line is displayed by default so it is unlikely > he wanted that. Column isn't, so maybe you > are right. > > However he said point "value", not "values", so > I think I'm right, still. > > Hey, not bad! Maybe I should be a private > investigator instead of a derailed programmer > and unauthorized bike repair shop operator? > Finding your true talent sure is difficult for > versatile people ;) [1] > > > [1] https://en.wikipedia.org/wiki/Hanau_epe > > -- > underground experts united > http://user.it.uu.se/~embe8573 > > > > > ------------------------------ > > Message: 2 > Date: Wed, 8 May 2019 17:29:51 -0300 > From: Mauro Aranda > To: Stefan Monnier > Cc: help-gnu-emacs@gnu.org > Subject: Re: Question about defcustom and load-history > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Stefan Monnier writes: > >>> This doesn't look intentional to me. Should I file a bug report? >> >> I haven't seen a corresponding bug-report, so I'll reply here. >> I installed the patch below into `master` which should fix this problem >> for good. >> >> >> Stefan > > Thank you Stefan! > > > ------------------------------ > > Message: 3 > Date: Thu, 9 May 2019 05:52:14 +0700 > From: Budi > To: help-gnu-emacs@gnu.org > Subject: Re: help-gnu-emacs Digest, Vol 198, Issue 27 > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Thanks.. all the feeding information is leading to the solution ! > > > > ------------------------------ > > Message: 4 > Date: Thu, 09 May 2019 03:40:10 +0200 > From: Emanuel Berg > To: help-gnu-emacs@gnu.org > Subject: Re: help-gnu-emacs Digest, Vol 198, Issue 27 > Message-ID: <86k1f0l81x.fsf@zoho.eu> > Content-Type: text/plain > > Budi wrote: > >> Thanks.. all the feeding information is >> leading to the solution ! > > When you get there, be sure to post it here as > well for other people do Google and find, and > also for other people to read and be amazed, > and also for other people to come with further > suggestions/comments if needed :) > > -- > underground experts united > http://user.it.uu.se/~embe8573 > > > > > ------------------------------ > > Message: 5 > Date: Thu, 9 May 2019 11:22:33 +0700 > From: Budi > To: help-gnu-emacs@gnu.org > Subject: How to clipboard copy emacs help text by user-made > interactive function kill-ring-save > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > I tried to clipboard copy some emacs read-only text by user-made > interactive function kill-ring-save, but fail > It's not M-w bound to kill-ring-save emacs built in function which is > working > > but as my preceding question, the copy : > > (defun copy (b e) > (interactive "r") > (if (use-region-p) (call-interactively 'kill-ring-save) > (save-excursion > (beginning-of-line) > (set-mark (line-end-position)) > (kill-ring-save (point)(mark)) > )))) > (global-set-key (kbd "C-c") 'copy) > > cannot copy such case above, > any idea what's actually made different behavior of kill-ring-save ? > > > > ------------------------------ > > Message: 6 > Date: Thu, 09 May 2019 07:36:09 +0200 > From: Emanuel Berg > To: help-gnu-emacs@gnu.org > Subject: Re: How to clipboard copy emacs help text by user-made > interactive function kill-ring-save > Message-ID: <86woj0jik6.fsf@zoho.eu> > Content-Type: text/plain > > Budi wrote: > >> I tried to clipboard copy some emacs >> read-only text by user-made interactive >> function kill-ring-save, but fail It's not >> M-w bound to kill-ring-save emacs built in >> function which is working > > I'll be happy to (try) to help you, but please > try to formulate the problem in terms of what > it is you want to happen, not in terms how how > you tried to do it already. It gets confused > that way :) > > You want to `kill-ring-save' the text in the > region? If so, just set it (the region) and hit > M-w :) > > -- > underground experts united > http://user.it.uu.se/~embe8573 > > > > > ------------------------------ > > Message: 7 > Date: Thu, 9 May 2019 11:49:15 +0200 > From: Ergus > To: Stefan Monnier > Cc: help-gnu-emacs@gnu.org > Subject: Re: Why is Elisp slow? > Message-ID: <20190509094915.zja6oba6dkpqnbpc@Ergus> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Hi: > > After some mails in the SBCL mailing list and make some > question-reply-question there; I arrived the conclusion that SBCL is not > an alternative :( I was very wrong. > > I'll copy-paste the main answers here just in case someone wants to go > this way in the future. Or in case someone more expert see some possible > workaround for the issues exposed here. > > ---------------------------------------- > > Your question as stated is too open-ended for me to discern the exact > intent, but I think's it's something like this: there is much common-lisp > code that people run in emacs, and you'd like not to have to maintain a > common-lisp compiler as well as elisp compiler. Instead you'd like to > retarget the output of the SBCL compiler to produce elisp byte code for > execution. > It's unclear whether you'd expect this to be an out-of-process compiler or > an in-process compiler. If in-process, then you've got larger problems > than figuring out how to call C. SBCL is not intended to be a "subsystem" > of other lisps, nor even to allow main() to be anything other than its own > main(), though that limitation has been relaxed a bit. > > If out-of-process, then I would imagine that SBCL would operate as a file > compiler only, and not a compiler of arbitrary forms. You need to figure > out how to treat emacs as the virtual machine which the SBCL compiler > targets, and a suitable interface for getting the compiled code out of an > SBCL '.fasl' file and into emacs. The "machine code" in the '.fasl' file > would actually be emacs byte code. (I'm assuming that you plan to keep > more-or-less the same byte code execution engine) > > I don't see why C functions are a particular problem. SBCL uses C > functions all the time. In fact it is extremely interoperable with C, but > that's really asking the wrong question imho. > Portability is the real question, since you brought it up. Are you implying > that SBCL's compiler should produce machine code that would run within > emacs? This is highly unlikely; I won't say impossible, but darn near so. > First of all, SBCL can produce machine code only for a tiny fraction of > the CPUs that emacs supports. Secondly, producing machine code assumes that > the entirety of the runtime (comprised of the memory layout, heap objects, > and support routines) is exactly as SBCL expects it to be - symbols look > like SBCL symbols, special variables get bound in exactly the way that SBCL > expects them to get bound. SBCL's compiled lisp files are not a portable > abstraction like a '.o' file (or '.so' if you like) that could be loaded > into *any* other program (a C program, Java program, etc) and just run. > > But as I said initially, I think you're trying to suggest that you would > produce code that is executed by the emacs lisp engine, not the CPU > directly. > So that would be essentially 1 new architecture that SBCL would have to > support, namely the emacs virtual machine. That sounds more plausible and > there's no reason to care about the set of CPUs that we can directly > compile for, nor even how the existing architectures would call C code. > You'd have to invent that as part of the retargeting to the emacs vm. > > Doug > > ---------------------------------------- > > I believe the most viable way to use SBCL for Emacs would be to rethink > the approach: instead of a graphics engine written in C - in addition to > many Lisp functions - and Elisp used to "script" that, with SBCL you no > longer need to have much of that C code for performance reasons. > > The entry point to this hypothetical new Emacs would be in Common Lisp, > as well as an Elisp environment that would be mostly macrology on top of > CL (to start with). After that, you could consider rewriting much of the > rendering engine into Lisp too, and leave only a tiny amount of C > strictly for interfacing with the operating system. > > I know some people have discussed about turning SBCL into a shared > library but the amount of work would be considerable and with little > gain because I doubt that the SBCL maintainers are interested in > committing to a stable C ABI to the compiler internals - otherwise > embedding SBCL into a C program would be of little use except for maybe > running CL away from the main thread. > > Stelian Ionescu > > ---------------------------------------- > > I expect portability to be a real issue here. If you *do* want to rely on > S= > BCL to generate native machine code for you, and abandon supporting > platfor= > ms that SBCL doesn't, that would be OK. This would entail significantly > mod= > ifying the Emacs runtime though. The SBCL compiler is married pretty > heavil= > y to its runtime (mainly through the GC, which is written in C), and SBCL > i= > s a small C program which simply jumps to the Lisp entry point in a large > L= > isp image and stays there in its own world, with its own calling > convention= > and object layour, occasionally calling back out to C for operating > system= > tools and GC, which understands Lisp objects and calling conventions. So > L= > isp/C interoperation works very well, but as others have stated, it works > i= > n a very SBCL-specific manner. I reckon the hard part would be getting the > = > C engine for Emacs to fit in the picture, hence the suggestion to rewrite > m= > uch of it in Lisp. > But the reality is I sort of doubt that eliminating support for a wide > vari= > ety of other architectures is acceptable to Emacs. Hence the suggestion to > = > create an Emacs bytecode backend. This would solve the portability > problem,= > at the cost of some efficiency. SBCL tries much harder than Emacs to > produ= > ce good code (by utilizing high level optimizations such as constraint > (e.g= > . type) propagation), however, so even then the bytecode produced by SBCL > w= > ould be superior compared to what Emacs can produce now. A problem with > thi= > s is that the compiler really does expect to be targeting a CPU ISA rather > = > than something higher level, so you'll have to be clever to figure out how > = > to set up the translation from the machine independent intermediate > represe= > ntation (IR2), and Elisp bytecode. > Finally, another option to reap the benefits of SBCL's fastish code > generat= > ion while not sacrificing portability is to figure out how to make Emacs a > = > portable Common Lisp program, through use of portable libraries for > foreign= > code interop, graphics, and Elisp (through macrology, most likely). Then > i= > t will run on all platforms that have C compilers through other Lisp > implem= > entations which do not target machine code (like ECL, CLISP, etc...) and > us= > e SBCL for the platforms it supports. This approach is taken by StumpWM, > wh= > ich is fairly similar to Emacs. > =20 > Charles > > ---------------------------------------- > > On Tue, May 07, 2019 at 10:22:39AM -0400, Stefan Monnier wrote: >>> embed ECL (Embeddable Common Lisp), which >>> * is significantly slower than SBCL, about 2~3x slower? but is still >>> much faster than Elisp. >> >>Last time this discussion came up, ECL seemed like the most promising >>option indeed, but the performance was not that impressive compared to >>Emacs. Maybe the situation has changed? >>Also in terms of maintenance, it's minimal, so it wouldn't help very >>much on the side of manpower. >> >> >> 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 28 > *********************************************** >