* Re: help-gnu-emacs Digest, Vol 198, Issue 25
[not found] <mailman.9306.1557236434.1166.help-gnu-emacs@gnu.org>
@ 2019-05-08 11:43 ` Budi
2019-05-08 14:09 ` Emanuel Berg
2019-05-08 14:18 ` how to show point value on strip/bar (aka modeline) [was: help-gnu-emacs Digest, Vol 198, Issue 25] tomas
0 siblings, 2 replies; 6+ messages in thread
From: Budi @ 2019-05-08 11:43 UTC (permalink / raw)
To: help-gnu-emacs
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
<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 <monnier@IRO.UMontreal.CA>
> To: ??? <pcr910303@icloud.com>
> Cc: Ergus <spacibba@aol.com>, help-gnu-emacs@gnu.org
> Subject: Re: Why is Elisp slow?
> Message-ID: <jwvsgtqfmw8.fsf-monnier+emacs@gnu.org>
> 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: ??? <pcr910303@icloud.com>
> To: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Ergus <spacibba@aol.com>, 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 <monnier@IRO.UMontreal.CA> ??:
>>
>>>> - 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 <monnier@IRO.UMontreal.CA>
> To: ??? <pcr910303@icloud.com>
> Cc: Ergus <spacibba@aol.com>, help-gnu-emacs@gnu.org
> Subject: Re: Why is Elisp slow?
> Message-ID: <jwvh8a6fmdm.fsf-monnier+emacs@gnu.org>
> 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 <spacibba@aol.com>
> To: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ??? <pcr910303@icloud.com>, 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: ??? <pcr910303@icloud.com>
> To: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Ergus <spacibba@aol.com>, 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 <monnier@IRO.UMontreal.CA> ??:
>>
>>>> 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 <spacibba@aol.com>
> To: ??? <pcr910303@icloud.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 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 <monnier@IRO.UMontreal.CA>
>>> ??????:
>>>
>>>>> 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
> ***********************************************
>
^ permalink raw reply [flat|nested] 6+ messages in thread