Re: help-gnu-emacs Digest, Vol 198, Issue 28

[Budi <budikusasi@gmail.com>]

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
<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 <moasenwood@zoho.eu>
> 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 <maurooaranda@gmail.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: Question about defcustom and load-history
> Message-ID:
> 	<CABczVwd1cE8iTiKHMAKe0JsoOmczrrDothEMVOxhMZAMWz=X6w@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Stefan Monnier <monnier@iro.umontreal.ca> 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 <budikusasi@gmail.com>
> To: help-gnu-emacs@gnu.org
> Subject: Re: help-gnu-emacs Digest, Vol 198, Issue 27
> Message-ID:
> 	<CAH0GyZDSJUEVQH5bbCHrW6n8iCjY0VpVX0G07zrpubz+NNrDBA@mail.gmail.com>
> 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 <moasenwood@zoho.eu>
> 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 <budikusasi@gmail.com>
> To: help-gnu-emacs@gnu.org
> Subject: How to clipboard copy emacs help text by user-made
> 	interactive	function kill-ring-save
> Message-ID:
> 	<CAH0GyZBWzD0J+qRtadN7bpBY6+5fVjtnPKS4KVE9HafzLKquQQ@mail.gmail.com>
> 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 <moasenwood@zoho.eu>
> 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 <spacibba@aol.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> 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
> ***********************************************
>