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

[Budi <budikusasi@gmail.com>]

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
> ***********************************************
>