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

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

[Budi]

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

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

[Emanuel Berg]

Budi wrote:

> How to make emacs always to show point value
> on strip/bar

The "mode line" is the Emacs term :)

> what workaround to get such if no standard
> menu exists

Put

    (:eval (format "p: %d " (point)))

in `mode-line-format', with
`setq-default'. Check out [1] for how it is
done, line ~37.

However... It only works when the mode line is
updated. By all means this happens when you
type, do M-x, and many other things, but not
when you just move point around w/o scrolling
the text, for example.

So then, point will be indicated as the same as
when the mode line was last updated! You can
`force-mode-line-update', manually, or schedule
it with the idle timer, perhaps.

But know that if you do it manually, that
amounts to just having a defun that echoes
point, and then invoke that when needed.
Perhaps typing a char, and then deleting it
immediately is faster tho, as this will be
enough to get an update.

On a personal note, I would get completely
crazy (I'm getting that already typing this!)
seeing at the same time the point value
incrementing for every char I type...

Also, I think, in principle, almost always
incorrect information at times is worse than no
information at all!

HIH @ 1569!


[1] https://dataswamp.org/~incal/emacs-init/mode-line.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to show point value on strip/bar (aka modeline) [was: help-gnu-emacs Digest, Vol 198, Issue 25]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Wed, May 08, 2019 at 06:43:53PM +0700, Budi wrote:
> How to make emacs always to show point value on  strip/bar
> 
> what workaround to get such if no standard menu exists

It does help to know how the strip/bar is called in Emacs
jargon: it's the "mode line".

You can find its settings via the menu "Options" -> "Customize Emacs" ->
"Top-level Customization Group", then follow the links "Environment" and
"Mode Line".

There are, of course, many other ways -- like M-x line-number-mode and
then M-x column-number-mode.

Searching the Emacs manual for "line number" or "column number would have
helped, too. "Strip" doesn't help and "bar" is too unspecific (49 hits).

(BTW: I changed the subject: your's wasn't very helpful to find help ;-)
HTH
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: how to show point value on strip/bar (aka modeline) [was: help-gnu-emacs Digest, Vol 198, Issue 25]

[Emanuel Berg]

tomas wrote:

>> How to make emacs always to show point value
>> on strip/bar
>> 
>> what workaround to get such if no standard
>> menu exists
>
> [...]
>
> There are, of course, many other ways -- like
> M-x line-number-mode and then M-x
> column-number-mode.

Hey Tomas, what was it you said the other day
about me not listening? :)

Because, as you know, line != point != column :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: how to show point value on strip/bar (aka modeline) [was: help-gnu-emacs Digest, Vol 198, Issue 25]

[tomas]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

On Wed, May 08, 2019 at 05:12:17PM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> >> How to make emacs always to show point value
> >> on strip/bar
> >> 
> >> what workaround to get such if no standard
> >> menu exists
> >
> > [...]
> >
> > There are, of course, many other ways -- like
> > M-x line-number-mode and then M-x
> > column-number-mode.
> 
> Hey Tomas, what was it you said the other day
> about me not listening? :)

Didn't mean that *I* listen always. But I try ;-)

> Because, as you know, line != point != column :)

That's right. I interpreted OP's "point" als the combination of
(line/column). But it's quite possible that I mis-interpreted
it.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: how to show point value on strip/bar (aka modeline) [was: help-gnu-emacs Digest, Vol 198, Issue 25]

[Emanuel Berg]

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