Emacs development

Emacs development

[Sam Auciello]

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

Hello, I am a long time user and appreciator of emacs and I am interested
in contributing to it.  I'm pretty comfortable with Lisp generally but not
super familiar with the inner workings of emacs (I've written few custom
macros for myself but I have yet to dive in much further).  I was wondering
if there were any issues I could look into (is there a bug tracker
somewhere that I am having trouble finding perhaps?)  Thanks in advance,
and I apologize if this was the wrong forum for this question.

Peace
~Antha

[-- Attachment #2: Type: text/html, Size: 582 bytes --]

Re: Emacs development

[Alexis]

Hi Sam,

Thanks for offering to help out Emacs!

On 2015-02-21T13:36:20+1100, Sam Auciello said:

 SA> Hello, I am a long time user and appreciator of emacs and I 
 am SA> interested in contributing to it.  I'm pretty comfortable 
 with Lisp SA> generally but not super familiar with the inner 
 workings of emacs SA> (I've written few custom macros for myself 
 but I have yet to dive SA> in much further).  I was wondering if 
 there were any issues I could SA> look into (is there a bug 
 tracker somewhere that I am having SA> trouble finding perhaps?) 
 Thanks in advance, and I apologize if SA> this was the wrong 
 forum for this question.

The bug tracker is here:

http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

If you want to contribute more than several lines of code to the 
GNU Emacs codebase, you'll need to complete copyright assignment 
paperwork; others here are better placed than i to provide you 
with the details.


Alexis.

Re: Emacs development

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Sat, 21 Feb 2015 14:52:44 +1100
> 
> The bug tracker is here:
> 
> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

Please also take a look at etc/TODO items.

Re: Emacs development

[Adam Sjøgren]

Alexis writes:

> On 2015-02-21T13:36:20+1100, Sam Auciello said:

> SA> Hello, I am a long time user and appreciator of emacs and I am SA>
> SA> interested in contributing to it. [...]

> The bug tracker is here:
>
> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

Lars Ingebrigtsen wrote a quick guide, "Welcome, New Emacs Developers",
after the Emacs code repository was converted to git, which might also
be of interest:

 * http://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-developers/


  Best regards,

    Adam

-- 
 "Oh, we all like motorcycles, to some degree."               Adam Sjøgren
                                                         asjo@koldfront.dk

Re: Emacs development

[Eric Abrahamsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Alexis writes:
>
>> On 2015-02-21T13:36:20+1100, Sam Auciello said:
>
>> SA> Hello, I am a long time user and appreciator of emacs and I am SA>
>> SA> interested in contributing to it. [...]
>
>> The bug tracker is here:
>>
>> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>
> Lars Ingebrigtsen wrote a quick guide, "Welcome, New Emacs Developers",
> after the Emacs code repository was converted to git, which might also
> be of interest:
>
>  * http://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-developers/

That's a good start, and you've got to draw a line someplace, but I
think a nice addition to the above would be: "what Emacs versions are
new contributions supposed to be compatible with," and "how to
compile/test your contributions."

I've embarrassed myself a few times recently, writing things that Worked
For Me, and not realizing that that wasn't enough.

Eric

Re: Emacs development

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 21 Feb 2015 19:28:34 +0800
> 
> > Lars Ingebrigtsen wrote a quick guide, "Welcome, New Emacs Developers",
> > after the Emacs code repository was converted to git, which might also
> > be of interest:
> >
> >  * http://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-developers/
> 
> That's a good start, and you've got to draw a line someplace, but I
> think a nice addition to the above would be: "what Emacs versions are
> new contributions supposed to be compatible with," and "how to
> compile/test your contributions."
> 
> I've embarrassed myself a few times recently, writing things that Worked
> For Me, and not realizing that that wasn't enough.

Please look at 'CONTRIBUTE' in the repository, which is intended to be
the official "Welcome, New Emacs Developers" write-up.  If what you
think should be there isn't, please don't hesitate to propose patches.

Thanks.

Re: Emacs development

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Sat, 21 Feb 2015 13:44:44 +0200

   Please look at 'CONTRIBUTE' in the repository, which is
   intended to be the official "Welcome, New Emacs Developers"
   write-up.  If what you think should be there isn't, please
   don't hesitate to propose patches.

That file is oriented to Emacs per se.  What is needed in
addition is some formalization of the relationship(s) between:

 - GNU Emacs, the source repo
 - GNU Emacs, the releases
 - ELPA
 - other emacsen

especially wrt lifetime and compatibility expectations.  IMHO,
this kind of inter-project policy-ish documentation should live
on Emacswiki.  Who will step up to write a first draft?

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs development

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sat, 21 Feb 2015 13:24:33 +0100
> 
>    Please look at 'CONTRIBUTE' in the repository, which is
>    intended to be the official "Welcome, New Emacs Developers"
>    write-up.  If what you think should be there isn't, please
>    don't hesitate to propose patches.
> 
> That file is oriented to Emacs per se.  What is needed in
> addition is some formalization of the relationship(s) between:
> 
>  - GNU Emacs, the source repo
>  - GNU Emacs, the releases
>  - ELPA
>  - other emacsen
> 
> especially wrt lifetime and compatibility expectations.

I'm not really sure I understand what these relationships are, or why
are they important.

> IMHO, this kind of inter-project policy-ish documentation should
> live on Emacswiki.

Then this is a separate issue, unrelated to newcomers to Emacs
development.

Re: Emacs development

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Sat, 21 Feb 2015 14:27:04 +0200

   I'm not really sure I understand what these relationships
   are, or why are they important.

Me too (re relationships), which is why it behooves those
involved to state them explicitly (if possible).  Re importance
of knowing these relationships: uncertainty leads to doubt, and
doubt leads to hesitation, incorrect assumptions, stumbling
execution and (in the worst cases) circular recriminations.

Knowing things beforehand helps conserve energy and good will.

   > IMHO, this kind of inter-project policy-ish documentation
   > should live on Emacswiki.

   Then this is a separate issue, unrelated to newcomers to
   Emacs development.

I think it is related in that a newcomer's contributions may
belong better in one repo or another, or even apart from Emacs
(e.g., posted to gnu-emacs-sources only), due to relationships
and expectations.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs development

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnu.org>
> Date: Sat, 21 Feb 2015 15:22:05 +0100
> 
>    I'm not really sure I understand what these relationships
>    are, or why are they important.
> 
> Me too (re relationships), which is why it behooves those
> involved to state them explicitly (if possible).

There are many issues that might or might not be related to Emacs; we
don't normally describe them just because they might.

You could help understanding how these are related, by posting
questions that might bother newcomers, for which there are no ready
answers in the available documentation.

> I think it is related in that a newcomer's contributions may
> belong better in one repo or another, or even apart from Emacs
> (e.g., posted to gnu-emacs-sources only), due to relationships
> and expectations.

We only have one repository these days.

Re: Emacs development

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Sat, 21 Feb 2015 20:43:50 +0200

   You could help understanding how these are related, by
   posting questions that might bother newcomers, for which
   there are no ready answers in the available documentation.

You need not look further than these (contemporary) threads:

- Move verilog-mode and vhdl-mode to elpa.gnu.org
- Proposal for a closed-buffer tracker

both of which...

   > [...] in one repo or another [...]

   We only have one repository these days.

...pose questions on which administrative domain (or "repo" for
short) is best aligned w/ the respective code.  So, maybe there
is only one repository in the strict technical sense (i haven't
checked), but certainly from the contributor pov, there is some
choosing among perceived alternatives required.

IIUC, in these examples, the contributors are both old and new,
but the nature of the questions are the same: "To decide where
to land, i want to know what is the landing zone like.  What is
the landing zone like?  If i land in one place, what travel (or
travails :-D) must i undertake to visit the other place?  What
are the border-crossing fees?  What kind of visa will i hold?"

And most importantly: "How volatile are the answers to the above
questions?  Is the overall relationship worth the commitment?"

Traditionally, and for the longest time (before ELPA and before
lexical-binding), the degenerate answer to both "relationship?"
and "expectation?" was "coherence".  This concept was easy to
grasp, judge, implement and compatibly uphold because of Emacs'
"fully singular" nature: one repo / dynamic-binding.

The overall cost of commitment was mostly fixed, w/ flexible
payment schedule as a nice bonus -- you could start w/ "‘setq’
groves in ~/.emacs" and work your way towards the mysteries of
‘(require 'cl)’ at whatever pace fit your fancy.

But those days are behind us now -- no complaints from me, i
hasten to add! -- and the context of the shared fruit plays a
larger part in its recipients' experience than ever.  Emacs is
no longer a simple punchbowl; it (and GNU ELPA and * ELPA and
gnu-emacs-sources and the Ferreted Wisdom of the Internet) is a
N-dish feast.  If i place on the table TTN-HACK, will it curdle
the lips of those who enjoy CORE-FEATURE-24?  CORE-FEATURE-25?
Or how about CORE-FEATURE-25 mixed w/ ELPA-ONLY-HACK-2012?  And
so on.  Of course the most important pondering almost goes w/o
saying: How can i protect my master-chef self-image?  :-D

"But ttn, you fool, you egoistic throwback!  Coherence is always
the answer -- that hasn't changed any!  You just have to look at
it in the right way (otherwise You're Doing It Wrong)."

Well it's true: the moiré i see the moiré i get confused...  :-D

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs development

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sat, 21 Feb 2015 19:28:34 +0800
>> 
>> > Lars Ingebrigtsen wrote a quick guide, "Welcome, New Emacs Developers",
>> > after the Emacs code repository was converted to git, which might also
>> > be of interest:
>> >
>> >  * http://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-developers/
>> 
>> That's a good start, and you've got to draw a line someplace, but I
>> think a nice addition to the above would be: "what Emacs versions are
>> new contributions supposed to be compatible with," and "how to
>> compile/test your contributions."
>> 
>> I've embarrassed myself a few times recently, writing things that Worked
>> For Me, and not realizing that that wasn't enough.
>
> Please look at 'CONTRIBUTE' in the repository, which is intended to be
> the official "Welcome, New Emacs Developers" write-up.  If what you
> think should be there isn't, please don't hesitate to propose patches.
>
> Thanks.

Done!

Re: Emacs development

[Filipp Gunbin]

On 21/02/2015 11:07 +0100, Adam Sjøgren wrote:

> Alexis writes:
>
>> On 2015-02-21T13:36:20+1100, Sam Auciello said:
>
>> SA> Hello, I am a long time user and appreciator of emacs and I am SA>
>> SA> interested in contributing to it. [...]
>
>> The bug tracker is here:
>>
>> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>
> Lars Ingebrigtsen wrote a quick guide, "Welcome, New Emacs Developers",
> after the Emacs code repository was converted to git, which might also
> be of interest:
>
>  *
>  http://lars.ingebrigtsen.no/2014/11/13/welcome-new-emacs-developers/

Thanks, I didn't know about the debbugs package mentioned there :)

Filipp

Emacs development...

[Jean-Christophe Helary]

It just occurred to me that there was no section in the manual dedicated to developing for emacs proper.

The CONTRIBUTE file is about administrative tasks.

Something like what the elisp intro is, but for general development.

For ex. is there a way to see the values of variables as I run the code, so that I don't need to modify the values of "message" here and there to have clues ?

What are the things I need to know and the basic steps to have a proper working environment to develop for emacs?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Eli Zaretskii]

> From: Jean-Christophe Helary <lists@traduction-libre.org>
> Date: Sat, 21 Aug 2021 14:07:59 +0900
> 
> It just occurred to me that there was no section in the manual dedicated to developing for emacs proper.

The ELisp Intro and the ELisp Reference are supposed to be it.

> Something like what the elisp intro is, but for general development.

What is the difference between "general development" and the other
kind (which presumably is covered in the Introduction)?

> For ex. is there a way to see the values of variables as I run the code, so that I don't need to modify the values of "message" here and there to have clues ?

See the chapter "Practicing Evaluation" in the ELisp Intro and
"Evaluation" in the ELisp Reference.

> What are the things I need to know and the basic steps to have a proper working environment to develop for emacs?

There are too many of them to answer such a general question.  It also
depends on your style of development.

Re: Emacs development...

[Jean-Christophe Helary]

Eli, apologies for the very general aspect of my question.

In the first version of this mail I was mentioning that my understanding of the development environment was not sufficient and made the study of the package.el code difficult.

Right now, I use C-h f to find the function definitions and move around the code.

But when I run package.el to test it, I'd like to have a way to examine the values of variables as they evolve. Right now I use message and check the *Messages* buffer... It is not ideal.

And there are probably a few other things that would make work easier but that I am not aware of because I am not a developer.

Jean-Christophe 

> On Aug 21, 2021, at 15:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Jean-Christophe Helary <lists@traduction-libre.org>
>> Date: Sat, 21 Aug 2021 14:07:59 +0900
>> 
>> It just occurred to me that there was no section in the manual dedicated to developing for emacs proper.
> 
> The ELisp Intro and the ELisp Reference are supposed to be it.
> 
>> Something like what the elisp intro is, but for general development.
> 
> What is the difference between "general development" and the other
> kind (which presumably is covered in the Introduction)?
> 
>> For ex. is there a way to see the values of variables as I run the code, so that I don't need to modify the values of "message" here and there to have clues ?
> 
> See the chapter "Practicing Evaluation" in the ELisp Intro and
> "Evaluation" in the ELisp Reference.
> 
>> What are the things I need to know and the basic steps to have a proper working environment to develop for emacs?
> 
> There are too many of them to answer such a general question.  It also
> depends on your style of development.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Tassilo Horn]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

Hi Jean-Christophe,

> Right now, I use C-h f to find the function definitions and move
> around the code.

That, and also M-. on a function call or variable will bring you to its
definition.

> But when I run package.el to test it, I'd like to have a way to
> examine the values of variables as they evolve. Right now I use
> message and check the *Messages* buffer... It is not ideal.

Try (info "(elisp) Edebug").  Especially (info "(elisp) Eval List")
seems relevant if you wan't to observe the value of some particular
variable at all times.

HTH,
Tassilo

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
> 
> Jean-Christophe Helary <lists@traduction-libre.org> writes:
> 
> Hi Jean-Christophe,
> 
>> Right now, I use C-h f to find the function definitions and move
>> around the code.
> 
> That, and also M-. on a function call or variable will bring you to its
> definition.

Thank you.

Sorry for this very basic question, what's the best way to navigate back to where I was ?

>> But when I run package.el to test it, I'd like to have a way to
>> examine the values of variables as they evolve. Right now I use
>> message and check the *Messages* buffer... It is not ideal.
> 
> Try (info "(elisp) Edebug").  Especially (info "(elisp) Eval List")
> seems relevant if you wan't to observe the value of some particular
> variable at all times.

Thank you Tassilo.

> 
> HTH,
> Tassilo

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Tassilo Horn]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

Hi Jean-Christophe,

>>> Right now, I use C-h f to find the function definitions and move
>>> around the code.
>> 
>> That, and also M-. on a function call or variable will bring you to
>> its definition.
>
> Thank you.
>
> Sorry for this very basic question, what's the best way to navigate
> back to where I was ?

I frequently use marks, i.e., hit C-SPC on an interesting place I wan't
to come back and C-u C-SPC to jump back to previous marks.  However,
that works only "intra-buffer".

I also use `imenu' a lot which is great if you already know where you
want to go, i.e., you know the name of the function or variable.

Also, isearch, occur, and rgrep.  And the consult package [1] offers
nice "go to thing" or "search for thing" commands.

Finally, I'm currently test-driving the dogears package [2] which tries
to provide a history of visited locations you can navigate back to by
using session-scoped (i.e., not persisted) bookmarks.  I currently use
this config:

--8<---------------cut here---------------start------------->8---
(use-package dogears
  :quelpa (dogears :fetcher github :repo "alphapapa/dogears.el")
  ;; These bindings are optional, of course:
  :bind (:map global-map
              ("M-g d" . dogears-go)
              ("M-g M-b" . dogears-back)
              ("M-g M-f" . dogears-forward)
              ("M-g M-l" . dogears-list)
              ("M-g M-r" . dogears-remember)
              ("M-g M-S" . dogears-sidebar))
  :config
  (setq dogears-limit 300)
  (setq dogears-line-width 30)

  ;; Ignored modes
  (add-to-list 'dogears-ignore-modes 'git-commit-mode)
  ;; This will try popping up gnus-summary-buffer which makes no sense with
  ;; mu4e.
  (add-to-list 'dogears-ignore-modes 'mu4e-view-mode)

  ;; Trigger functions
  (add-to-list 'dogears-functions 'kill-ring-save)

  ;; Trigger hooks
  (add-hook 'dogears-hooks 'after-change-functions)
  :init
  (dogears-mode))
--8<---------------cut here---------------end--------------->8---

dogears will atomatically remember the current location after 5 seconds
by default of idle time (assuming that you probably are reading
concentrated).  My config of `dogears-functions' and `dogears-hooks'
remember places where I've copied text or edited which are most probably
interesting enough I wanna come back.

Bye,
Tassilo

[1] https://github.com/minad/consult
[2] https://github.com/alphapapa/dogears.el

Re: Emacs development...

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Sat, 21 Aug 2021 09:54:51 +0200
> 
> >> That, and also M-. on a function call or variable will bring you to
> >> its definition.
> >
> > Thank you.
> >
> > Sorry for this very basic question, what's the best way to navigate
> > back to where I was ?
> 
> I frequently use marks, i.e., hit C-SPC on an interesting place I wan't
> to come back and C-u C-SPC to jump back to previous marks.  However,
> that works only "intra-buffer".

Doesn't M-, do what Jean-Christophe wants?

Re: Emacs development...

[Arthur Miller]

Tassilo Horn <tsdh@gnu.org> writes:

> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>
> Hi Jean-Christophe,
>
>>>> Right now, I use C-h f to find the function definitions and move
>>>> around the code.
>>> 
>>> That, and also M-. on a function call or variable will bring you to
>>> its definition.
>>
>> Thank you.
>>
>> Sorry for this very basic question, what's the best way to navigate
>> back to where I was ?
>
> I frequently use marks, i.e., hit C-SPC on an interesting place I wan't
> to come back and C-u C-SPC to jump back to previous marks.  However,
> that works only "intra-buffer".
C-x C-SPC for cross-buffer

> I also use `imenu' a lot which is great if you already know where you
> want to go, i.e., you know the name of the function or variable.
>
> Also, isearch, occur, and rgrep.  And the consult package [1] offers
> nice "go to thing" or "search for thing" commands.
And helm versions of those for nice, complete-as-you-type style of
navigation.

Re: Emacs development...

[Stephen Berman]

On Sat, 21 Aug 2021 16:50:31 +0900 Jean-Christophe Helary <lists@traduction-libre.org> wrote:

>> On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
>> 
>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>> 
>> Hi Jean-Christophe,
>> 
>>> Right now, I use C-h f to find the function definitions and move
>>> around the code.
>> 
>> That, and also M-. on a function call or variable will bring you to its
>> definition.
>
> Thank you.
>
> Sorry for this very basic question, what's the best way to navigate back to
> where I was ?

Maybe this (which should probably be mentioned in the doc string of
xref-find-definitions, i.e. M-.):

  M-, runs the command xref-pop-marker-stack (found in global-map), which is an
  interactive native compiled Lisp function in ‘xref.el’.
  
  It is bound to M-,.
  
  (xref-pop-marker-stack)
  
    Probably introduced at or before Emacs version 25.1.
  
  Pop back to where M-. was last invoked.

Steve Berman

Re: Emacs development...

[Konstantin Kharlamov]

On Sat, 2021-08-21 at 16:50 +0900, Jean-Christophe Helary wrote:
> 
> 
> > On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
> > 
> > Jean-Christophe Helary <lists@traduction-libre.org> writes:
> > 
> > Hi Jean-Christophe,
> > 
> > > Right now, I use C-h f to find the function definitions and move
> > > around the code.
> > 
> > That, and also M-. on a function call or variable will bring you to its
> > definition.
> 
> Thank you.
> 
> Sorry for this very basic question, what's the best way to navigate back to
> where I was ?

Seems to me, you don't have a workflow yet for development in general through Emacs. Because questions like "how to go to definition" and "how to go back" aren't really specific to ELisp, it's something you'd use while working with pretty much any language, be it C, Python, Haskell, C++, Rust… The only question you asked specific to ELisp is about debugging ELisp code.

This is okay ofc, I'm just pointing it out because it might give you some ideas on what to look for.

There's a popular opinion that default Emacs keybindings aren't the best, and people usually reconfigure some of them as they find appropriate.

And there're many different workflows for code/text navigation in Emacs. For example, I personally prefer using Evil plugin (a vim-mode inside Emacs, but it actually had more features than the actual vim), and using C-o, C-i in "normal mode" of Evil to go back and forth between locations in text. By default it may switch buffers which I don't like, so I disabled that. "going to definition" I personally bound to "gd" in normal mode of Evil. And then, inside a single file there are usually multiple specific places that are of interest to me, so I set marks to them with (again, keybinding specific to Evil) "m1", "m2", "m3"… i.e. just enumerating them in an order I find interesting.

There's also "avy" package for faster navigation within the visible text portions.

There are also Emacs "starter-kits" with lots of preconfigured stuff, e.g. Doom Emacs I heard is very good (I never personally used it, because by the time it became popular I already had a personalized configuration, however people seem to like it).

So, yeah, for things non-specific to ELisp development (which is so far was everything you mentioned except ELisp debugging), you just need to start trying to do the development, and along the way to try to reflect "what I really wish I was able to do right now". Stuff like autocompletion, seeing function help in a minibuffer or elsewhere, going to definition… Whatever you think of, it is probably implemented in Emacs (with or without plugins), so you just try to search for it using your favorite search engine.

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 21, 2021, at 21:05, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
> 
> On Sat, 2021-08-21 at 16:50 +0900, Jean-Christophe Helary wrote:
>> 
>> 
>>> On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
>>> 
>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>> 
>>> Hi Jean-Christophe,
>>> 
>>>> Right now, I use C-h f to find the function definitions and move
>>>> around the code.
>>> 
>>> That, and also M-. on a function call or variable will bring you to its
>>> definition.
>> 
>> Thank you.
>> 
>> Sorry for this very basic question, what's the best way to navigate back to
>> where I was ?
> 
> Seems to me, you don't have a workflow yet for development in general through Emacs. Because questions like "how to go to definition" and "how to go back" aren't really specific to ELisp, it's something you'd use while working with pretty much any language, be it C, Python, Haskell, C++, Rust… The only question you asked specific to ELisp is about debugging ELisp code.

Thank you Konstantin

I guess that's the case, but I was not even asking for *debugging*, just to see how values change over the run of a piece of code. If *that* is called "debugging", there is a discoverability issue.

I saw the EDE mode but even after reading its manual I was not sure how that could be put to use to ease work inside Emacs list code.

So I guess I'll stick to edebug, M-. and M-, eldoc, highlight-defined, which-key, helpful. Right now they seem to be a good minimal setting for what I want to do.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Tim Cross]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 21, 2021, at 21:05, Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
>> 
>> On Sat, 2021-08-21 at 16:50 +0900, Jean-Christophe Helary wrote:
>>> 
>>> 
>>>> On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
>>>> 
>>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>> 
>>>> Hi Jean-Christophe,
>>>> 
>>>>> Right now, I use C-h f to find the function definitions and move
>>>>> around the code.
>>>> 
>>>> That, and also M-. on a function call or variable will bring you to its
>>>> definition.
>>> 
>>> Thank you.
>>> 
>>> Sorry for this very basic question, what's the best way to navigate back to
>>> where I was ?
>> 
>> Seems to me, you don't have a workflow yet for development in general through
>> Emacs. Because questions like "how to go to definition" and "how to go back"
>> aren't really specific to ELisp, it's something you'd use while working with
>> pretty much any language, be it C, Python, Haskell, C++, Rust… The only
>> question you asked specific to ELisp is about debugging ELisp code.
>
> Thank you Konstantin
>
> I guess that's the case, but I was not even asking for *debugging*, just to see
> how values change over the run of a piece of code. If *that* is called
> "debugging", there is a discoverability issue.
>
> I saw the EDE mode but even after reading its manual I was not sure how that
> could be put to use to ease work inside Emacs list code.
>
> So I guess I'll stick to edebug, M-. and M-, eldoc, highlight-defined,
> which-key, helpful. Right now they seem to be a good minimal setting for what I
> want to do.

I would also recommend getting comfortable with ielm (M-x ielm), an
Interactive Emacs Lisp Mode, as well as learning how to evaluate
expressions in the source buffer. 

A common 'development' pattern with lisp like languages is sometimes
referred to as "REPL driven development". This is where you
incrementally build up your code, running and testing small bits in the
REPL as you go. You can do things like execute single s-expressions to
see what value they return. This can be a really useful way to also
learn about a bit of code - essentially, you can 'explore' what each
statement does/returns.

Initially, you will probably need to add message statements to print out
variable values and state at various points in the code. However, as
your knowledge and confidence grows, you will find this less and less
necessary.

While having tools like edebug can be extremely useful, I don't think
focusing on them is a terribly useful approach. I find the debugger to
be the tool of last resort - I turn to it when I'm completely lost and
cannot work out why something is not working correctly. When you get to
that point, it can be invaluable. However, adopting a debugging approach
based around tracing code and stepping through it, watching variables
change etc is tedious and time consuming. Focus on the logic and
understanding/interpreting the code and documentation and I suspect you
will progress faster and find it more enjoyable. A few minutes scanning
and really understanding the code will often be much faster than
starting edebug, instrumenting functions and tediously stepping through
the code watching variables change. You may be surprised at how quickly
you develop the skill of being able to just look at a bit of code and
understand exactly what it does.

However, the most critical bit of advice I can give is 'just do it'.
Don't get too caught up in tools and workflows. Just get in there and
start writing code. Initially, it will probably be rubbish. However, the
process is crucial. You will learn more from sitting and trying to write
some code than you will from hours of scanning documents, manuals and
blog posts on how to develop. It is also through writing code you will
learn what you find to be the biggest 'pain points'. This will gide you
on what workflow and combination of tools/modes etc are best suited to
your needs. Without that knowledge, it can all be a bit too abstract and
overwhelming.

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
> 
> I would also recommend getting comfortable with ielm (M-x ielm), an
> Interactive Emacs Lisp Mode, as well as learning how to evaluate
> expressions in the source buffer. 

Thank you Tim for the suggestion. I like ielm a lot, when I use it.

What I am trying to do now is fix a bug in package.el and I don't see how I can use ielm for that. Do you have suggestions ?

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Tim Cross]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>> 
>> I would also recommend getting comfortable with ielm (M-x ielm), an
>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>> expressions in the source buffer. 
>
> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>
> What I am trying to do now is fix a bug in package.el and I don't see how I can
> use ielm for that. Do you have suggestions ?

The relevance of ielm is that it is a powerful and useful tool you have
at hand when doing development or bug fixing in elisp. It provides the
REPL where you can test/evaluate bits of code. How useful it is for a
specific issue will depend on that issue. 

It seems like you may be looking for a basic recipe for how you find and
fix a bug in elisp. There is no such thing. Every bug is different. The
one thing which is consistent is the need to understand the environment
and available tools. The main point I wanted to make is that the Emacs
debugger, while a very useful tool, is not where I would focus
initially. I feel it is often a mistake for people to immediately think
that when trying to track down a bug, the first thing you do is fire up
edebug. Most of the time, it is the last thing I use - in fact, for most
bug fixing or elisp development, I never use it. It I had to rank the
tools from most important/useful to least, it would probably be
something like

- Emacs built-in help system (including using info effectively). Looking
  up information about functions and variables, current configuration
  settings, key bindings, finding relevant functions/variables etc.

- Using debug-on-error and debug-on-quit to generate backtraces -
  essential tools to identify the point in the code where things go
  wrong, allowing you to work backwards to find out why. 

- emacs=lisp-mode - navigating around the code, finding definitions,
  evaluating expressions etc

- ielm and *scratch* buffer in elisp mode - entering expressions, using
  history, pasting and yanking code etc. 

- edebug - for stepping and tracing through code

- gdb - for those rarer cases where you need to dive into low level C stuff

When trying to track down a bug, I find the most important first step is
to try and identify the minimal recipe to reliably reproduce the issue.
If you cannot reproduce it, you are unlikely to be able to fix it. Even
if you think you have fixed it, you won't know for sure unless you know
how to reproduce it. Once you know the minimal environment configuration
needed to trigger the bug, you will have a better idea where in the code
the bug is likely located and can study that bit of code to understand
how it works. To understand it, you will likely need to lookup the docs
for functions and variables involved and possibly try executing
functions/commands in ielm to see what they return based on different
input values etc. At this point, your objective is to narrow the search
space as far as possible. Ideally, you will narrow things down to a
single function or a couple of functions.

Once you get to this point, how you will progress will depend a lot on
the type of bug. For example, sometimes you might be able to create a
minimal test environment using the scratch buffer and ielm. You might
copy the function to the scratch buffer, give it a new name, evaluate it
and try running it with different input values. Sometimes, the type of
bug will not lend itself to doing this - for example, a UI bug in a
major mode might be difficult to 'extract' because of too many
dependencies in the modes local environment. You might need
to spend time configuring a test environment by defining variables in a
scratch buffer which you can set to different values and then execute
the command multiple times within your 'artificial' test environment.
Sometimes, it will be almost trivial - you will scan the code and a
single expression will jump out as a likely candidate and a few test
evaluations with different inputs will identify the cause.

The key is to narrow down the issue to the smallest amount of code
possible and then focus on understanding how that code works - not just
what variables change and when, but understand the logic behind he code.
Understand what the intention of the code is and identify where that
intention and actual behaviour differ. At this point, the most important
resource at your disposal is you - it is your understanding of the code
which will determine how quickly you understand the bug and can identify
how to resolve it.

The main limitation with edebug (with debuggers generally), is that it
doesn't really help with understanding the logic and intention of the
code. It can help with understanding the 'mechanics' - what gets run
when and what gets set to what value at what point etc. However, this
rarely helps explain why. You may identify when a variable gets set to
the wrong value, but not why it ended up with the wrong value. Knowing
when it gets set to the wrong value can be useful, but often, if you
really understand the code, you can already see this by just running the
steps through mentally. 

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 22, 2021, at 8:09, Tim Cross <theophilusx@gmail.com> wrote:
> 
> 
> Jean-Christophe Helary <lists@traduction-libre.org> writes:
> 
>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>> 
>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>> expressions in the source buffer. 
>> 
>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>> 
>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>> use ielm for that. Do you have suggestions ?
> 
> It seems like you may be looking for a basic recipe for how you find and
> fix a bug in elisp.

Thank you Tim for your detailed reply.

I am myself guilty of replying to threads that I have not fully read so I won't complain, but I did send a clarification mail after my very first super generic mail, where I clearly stated that I was looking for a method to see how variable values evolve over the running of some code.

It seems that the common answer to that is edebug, and I think I understand what you mean by "it doesn't really help with understanding the logic and intention of the code. It can help with understanding the ’mechanics’".

> - Emacs built-in help system (including using info effectively). Looking
>  up information about functions and variables, current configuration
>  settings, key bindings, finding relevant functions/variables etc.

I can do that. I'm using "inform" and "helpful" already and they are indeed very helpful in finding extra info about functions, etc.

> - Using debug-on-error and debug-on-quit to generate backtraces -
>  essential tools to identify the point in the code where things go
>  wrong, allowing you to work backwards to find out why.

I just read their description and they'll probably be useful at one point but since there is no "error" in the package.el code (in the meaning that an error would stop the execution of the code, or produce something similar), I'm not sure how I can use them for my purpose right now, but I'll keep them in mind.

> - emacs=lisp-mode - navigating around the code, finding definitions,
>  evaluating expressions etc

The suggestions I got about M-. and M-, were invaluable. They already tremendously improved my navigation of the code.

> - ielm and *scratch* buffer in elisp mode - entering expressions, using
>  history, pasting and yanking code etc.

I do that already.

> - edebug - for stepping and tracing through code

I guess that's the one where I can see how values evolve.

> - gdb - for those rarer cases where you need to dive into low level C stuff

Unlikely.

> When trying to track down a bug, I find the most important first step is
> to try and identify the minimal recipe to reliably reproduce the issue.

In the case at hand, it is 100% reproducible, I mentioned it in a mail I sent here with the title "package.el, a bug ? and a UX issue ?".

I've already fixed stuff in package.el in the past, mostly improper use of strings, not bugs per se. I wanted to further improve on that when I found that glaring bug that I'm surprised nobody noticed yet:

mark for upgrade with U
filter on marked with / m
remove the filter with / /
the marks for upgrade are gone.

generally speaking / / will remove any mark, not just upgrade ones. I guess the fact that this bug has remained in the code for so longs says something about how often the filter feature is used.

Thank you very much for the following paragraphs. They are an excellent description of what debugging involves, which I have practiced in other contexts (namely AppleScript stuff that I develop for myself) even if at a much lower level.

I'm glad I started this thread.

Jean-Christophe

> If you cannot reproduce it, you are unlikely to be able to fix it. Even
> if you think you have fixed it, you won't know for sure unless you know
> how to reproduce it. Once you know the minimal environment configuration
> needed to trigger the bug, you will have a better idea where in the code
> the bug is likely located and can study that bit of code to understand
> how it works. To understand it, you will likely need to lookup the docs
> for functions and variables involved and possibly try executing
> functions/commands in ielm to see what they return based on different
> input values etc. At this point, your objective is to narrow the search
> space as far as possible. Ideally, you will narrow things down to a
> single function or a couple of functions.
> 
> Once you get to this point, how you will progress will depend a lot on
> the type of bug. For example, sometimes you might be able to create a
> minimal test environment using the scratch buffer and ielm. You might
> copy the function to the scratch buffer, give it a new name, evaluate it
> and try running it with different input values. Sometimes, the type of
> bug will not lend itself to doing this - for example, a UI bug in a
> major mode might be difficult to 'extract' because of too many
> dependencies in the modes local environment. You might need
> to spend time configuring a test environment by defining variables in a
> scratch buffer which you can set to different values and then execute
> the command multiple times within your 'artificial' test environment.
> Sometimes, it will be almost trivial - you will scan the code and a
> single expression will jump out as a likely candidate and a few test
> evaluations with different inputs will identify the cause.
> 
> The key is to narrow down the issue to the smallest amount of code
> possible and then focus on understanding how that code works - not just
> what variables change and when, but understand the logic behind he code.
> Understand what the intention of the code is and identify where that
> intention and actual behaviour differ. At this point, the most important
> resource at your disposal is you - it is your understanding of the code
> which will determine how quickly you understand the bug and can identify
> how to resolve it.
> 
> The main limitation with edebug (with debuggers generally), is that it
> doesn't really help with understanding the logic and intention of the
> code. It can help with understanding the 'mechanics' - what gets run
> when and what gets set to what value at what point etc. However, this
> rarely helps explain why. You may identify when a variable gets set to
> the wrong value, but not why it ended up with the wrong value. Knowing
> when it gets set to the wrong value can be useful, but often, if you
> really understand the code, you can already see this by just running the
> steps through mentally. 
> 

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Tim Cross]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>
> mark for upgrade with U
> filter on marked with / m
> remove the filter with / /
> the marks for upgrade are gone.
>
> generally speaking / / will remove any mark, not just upgrade ones. I guess the
> fact that this bug has remained in the code for so longs says something about
> how often the filter feature is used.
>
Yes, I never use it :-).

I guess I'd probably classify this as a specification bug rather than a
more fundamental bug. Exactly what / / clears needs to be clarified. Is
there a use case where you would actually want the upgrade marks removed
as well? Perhaps the simplicity of clearing all marks and then just
running package-refresh-contents to get back the list of packages which
can be upgraded is a justifiable approach which keeps the filter removal
function less complex and therefore less error prone?

It could be nobody has reported this as a bug because they don't
consider it to be a bug. There doesn't seem to be anything in the
documentation which would make me expect upgrade marks would not be
removed, so I would probably consider what you are proposing as a
feature enhancement rather than a bug fix. Then again, as I stated, I
don't use this function, so really don't have any skin in the game. 

Re: Emacs development...

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>
>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>> 
>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>> expressions in the source buffer. 
>>
>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>
>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>> use ielm for that. Do you have suggestions ?
>
> The relevance of ielm is that it is a powerful and useful tool you have
> at hand when doing development or bug fixing in elisp. It provides the
> REPL where you can test/evaluate bits of code. How useful it is for a
> specific issue will depend on that issue. 

What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
interested to know if I can improve on my workflow. 


> The main limitation with edebug (with debuggers generally), is that it
> doesn't really help with understanding the logic and intention of the
> code. It can help with understanding the 'mechanics' - what gets run
> when and what gets set to what value at what point etc. However, this
> rarely helps explain why. You may identify when a variable gets set to
> the wrong value, but not why it ended up with the wrong value. Knowing
> when it gets set to the wrong value can be useful, but often, if you
> really understand the code, you can already see this by just running the
> steps through mentally. 
You have a point there, but in many cases people are not really sure
what value is passed into variable, so they will printf or message in
elisp, something just to see the value so they can identify which piece
of code it gets.

In that particular case, I would suggest that debugger is to prefer,
instead of adding a printf statememnt which will go away in a seconds
after.

Before I learned to use a debugger it could have being a lot
of System.out.println statements, to the point I needed to search the
output in a text editor. It was many years ago when even grep was an
esoteric command for me :).

Re: Emacs development...

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>
>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>> 
>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>> expressions in the source buffer. 
>>>
>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>
>>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>>> use ielm for that. Do you have suggestions ?
>>
>> The relevance of ielm is that it is a powerful and useful tool you have
>> at hand when doing development or bug fixing in elisp. It provides the
>> REPL where you can test/evaluate bits of code. How useful it is for a
>> specific issue will depend on that issue. 
>
> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
> interested to know if I can improve on my workflow. 
>

Evaluating sexp in the code is very valuable. However, sometimes, I just
want to execute functions or parts of functions outside the context of
the code file. I might just want to verify my understanding of how a
function works, or call it with different arguments or modify something
etc. I'm not suggesting ielm as an alternative, but rather an addition
to the set of tools/techniques used. 

>
>> The main limitation with edebug (with debuggers generally), is that it
>> doesn't really help with understanding the logic and intention of the
>> code. It can help with understanding the 'mechanics' - what gets run
>> when and what gets set to what value at what point etc. However, this
>> rarely helps explain why. You may identify when a variable gets set to
>> the wrong value, but not why it ended up with the wrong value. Knowing
>> when it gets set to the wrong value can be useful, but often, if you
>> really understand the code, you can already see this by just running the
>> steps through mentally. 
> You have a point there, but in many cases people are not really sure
> what value is passed into variable, so they will printf or message in
> elisp, something just to see the value so they can identify which piece
> of code it gets.
>
> In that particular case, I would suggest that debugger is to prefer,
> instead of adding a printf statememnt which will go away in a seconds
> after.

I personally find doing things like that much faster and less hassle
than firing up the debugger, instrumenting functions and stepping
through code.

Everyone will have their own style. I've seen lots of people who depend
heavily on debuggers. I rarely use them for any language. Debugging is
tedious enough without making it worse IMO.

A lot can also depend on the quality of the code. If you have lots of
code which depends on side effects all over the place, then sometimes a
debugger is the only way you can try and track down the problem. On the
other hand, clean functional code which avoids side effects tends to be
easier as you can clearly see where and how things get modified without
having to watch for changes or trace code execution. 

Different languages can also change the equation a bit. I am more likely
to use a debugger when working in C or assembly, but never when working
with CL, Clojure, javascript, elisp etc. I might with Java, but then
again, if I'm forced to do java, I'm already bored and no longer having
fun!

>
> Before I learned to use a debugger it could have being a lot
> of System.out.println statements, to the point I needed to search the
> output in a text editor. It was many years ago when even grep was an
> esoteric command for me :).

All depends on how you use/add those statements. If you find it
necessary to search through heaps of lines of output, I would argue you
are not using the statements judiciously. You add statements where they
are beneficial and remove them as soon as there not. Same with using the
debugger - you don't instrument everything and watch all the variables -
you apply things judiciously and clean up as you go. 

Re: Emacs development...

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>
>>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>>> 
>>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>>> expressions in the source buffer. 
>>>>
>>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>>
>>>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>>>> use ielm for that. Do you have suggestions ?
>>>
>>> The relevance of ielm is that it is a powerful and useful tool you have
>>> at hand when doing development or bug fixing in elisp. It provides the
>>> REPL where you can test/evaluate bits of code. How useful it is for a
>>> specific issue will depend on that issue. 
>>
>> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
>> interested to know if I can improve on my workflow. 
>>
>
> Evaluating sexp in the code is very valuable. However, sometimes, I just
What do you mean in the code? Like C-x C-e?

M-: opens a repl, similar to ielm. It places cursor in minibuffer and
lets me eval a function with any arguments and so. Ielm asks me to keep
a prompt open in another buffer. So I have to switch to and from that
buffer, so I never really appreciate it. So I wonder if ielm has
something more to offer, than what I get from M-:?

> want to execute functions or parts of functions outside the context of
> the code file. I might just want to verify my understanding of how a
> function works, or call it with different arguments or modify something
> etc. I'm not suggesting ielm as an alternative, but rather an addition
> to the set of tools/techniques used. 
>
>>
>>> The main limitation with edebug (with debuggers generally), is that it
>>> doesn't really help with understanding the logic and intention of the
>>> code. It can help with understanding the 'mechanics' - what gets run
>>> when and what gets set to what value at what point etc. However, this
>>> rarely helps explain why. You may identify when a variable gets set to
>>> the wrong value, but not why it ended up with the wrong value. Knowing
>>> when it gets set to the wrong value can be useful, but often, if you
>>> really understand the code, you can already see this by just running the
>>> steps through mentally. 
>> You have a point there, but in many cases people are not really sure
>> what value is passed into variable, so they will printf or message in
>> elisp, something just to see the value so they can identify which piece
>> of code it gets.
>>
>> In that particular case, I would suggest that debugger is to prefer,
>> instead of adding a printf statememnt which will go away in a seconds
>> after.
>
> I personally find doing things like that much faster and less hassle
> than firing up the debugger, instrumenting functions and stepping
> through code.
>
> Everyone will have their own style. I've seen lots of people who depend
> heavily on debuggers. I rarely use them for any language. Debugging is
> tedious enough without making it worse IMO.
>
> A lot can also depend on the quality of the code. If you have lots of
> code which depends on side effects all over the place, then sometimes a
> debugger is the only way you can try and track down the problem. On the
> other hand, clean functional code which avoids side effects tends to be
> easier as you can clearly see where and how things get modified without
> having to watch for changes or trace code execution. 
>
> Different languages can also change the equation a bit. I am more likely
> to use a debugger when working in C or assembly, but never when working
> with CL, Clojure, javascript, elisp etc. I might with Java, but then
> again, if I'm forced to do java, I'm already bored and no longer having
> fun!
Indeed. I have to admit I am a bit lazy sometimes and use message if I
am just doing some quick thing. But generally I prefer debugger. In
c/c++ it is out of question to debug with printfs. I haven't wrote a
line of Java since 15 years back, so I can share your taste for fun,
definitely :).
>>
>> Before I learned to use a debugger it could have being a lot
>> of System.out.println statements, to the point I needed to search the
>> output in a text editor. It was many years ago when even grep was an
>> esoteric command for me :).
>
> All depends on how you use/add those statements. If you find it
> necessary to search through heaps of lines of output, I would argue you
> are not using the statements judiciously. You add statements where they
> are beneficial and remove them as soon as there not. Same with using the
> debugger - you don't instrument everything and watch all the variables -
> you apply things judiciously and clean up as you go. 

Yep, I was young and innexperienced. Also nobody thought at university
how to use a debugger (or other tools like make & co really). It was all
about taxonomies from dinosaurus to mamal, cars with different colours
and all kind of persons and how they will keep track of their age and
such.

Re: Emacs development...

[Tim Cross]

Arthur Miller <arthur.miller@live.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> Arthur Miller <arthur.miller@live.com> writes:
>>
>>> Tim Cross <theophilusx@gmail.com> writes:
>>>
>>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>>
>>>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>>>> 
>>>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>>>> expressions in the source buffer. 
>>>>>
>>>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>>>
>>>>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>>>>> use ielm for that. Do you have suggestions ?
>>>>
>>>> The relevance of ielm is that it is a powerful and useful tool you have
>>>> at hand when doing development or bug fixing in elisp. It provides the
>>>> REPL where you can test/evaluate bits of code. How useful it is for a
>>>> specific issue will depend on that issue. 
>>>
>>> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
>>> interested to know if I can improve on my workflow. 
>>>
>>
>> Evaluating sexp in the code is very valuable. However, sometimes, I just
> What do you mean in the code? Like C-x C-e?
>
> M-: opens a repl, similar to ielm. It places cursor in minibuffer and
> lets me eval a function with any arguments and so. Ielm asks me to keep
> a prompt open in another buffer. So I have to switch to and from that
> buffer, so I never really appreciate it. So I wonder if ielm has
> something more to offer, than what I get from M-:?
>

M-: isn't what I would call a REPL. It just provides a way to evaluate a
lisp expression which you can enter in the echo area. It is similar to
eval-last-sexp (C-x C-e), except as you say, you can specify the arguments.

Where ielm differs is that it is more like a proper REPL - it adds the
'L' (loop) which you don't have with M-:, which is really just the REP
(read, eval print) part. With ielm you can enter multiple statements, go back
through history and edit/modify an expression and re-evaluate it. Define
a new function and then call it, set a variable and then see its printed
form by just typing it at the prompt etc. I also find it a lot easier
when entering more complex expressions than just using the minibuffer
with M-:.

When I'm writing new eilsp, I will often open a new *.el file and a ielm
buffer. I might write the first pass of a function in ielm, run it with
different arguments until it works as desired and then copy it back to
the *.el file to save it.

I don't find it an issue to switch buffers - this is what I'm doing all
the time. I have a frame with multiple tabs and each tab might have
multiple windows and I will jump around between them constantly. It only
takes one or two key strokes, so I find it no more hassle than M-:.

Being able to edit more complex expressions and move up/down through the
history is extremely useful. However, I also really enjoy interactive
development and exploration. I hate writing a whole heap of code and
then having to spend hours debugging it. I prefer to write small
functions and build them up bit by bit, running and testing them as I
go. For this, ielm is a key tool. 

What would be even better is the ability to send code from the buffer to
be evaluated in the ielm buffer. I think Stefan posted something about
this recently. This could make it easier to execute expressions within a
context you have created and provide some additional functionality which
isn't easily done now (though of course, being Emacs, you can set it up).

To what extent you would find ielm useful really depends on personal taste
and style when it comes to development and/or debugging. This is both
the power and weakness of Emacs. It is powerful because you can create
the workflow which is more natural and customised to individual tastes.
It is a weakness because 'out of the box', things are very vanilla and
it can take time to learn what is possible and configure it. To be
honest, my current emacs lisp environment is nowhere as refined and
configured as it once was. Back when I was doing more elisp, things were
heavily customised with many advanced features enabled, custom key
bindings, additional functions, advice etc etc. However, I rarely find
it necessary to do much elisp these days. I've even stopped maintaining
my own emacs configuration and now just use spacemacs - I have always
liked VI's modal editing style and I find spacemacs mostly works really
well. I have some fairly minor tweaks and customisation, but on the
whole, I just leave it alone and get on with the other stuff I need to
do. 

Re: Emacs development...

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 5313 bytes --]

Tim Cross <theophilusx@gmail.com> writes:


In addition to all you say below re IELM, the nugget of gold that makes
it invaluable is its ability to  set the eval context buffer while
remaining in the ielm buffer, see command bound to C-c b.
> Arthur Miller <arthur.miller@live.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>
>>>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>>>
>>>>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>>>>> 
>>>>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>>>>> expressions in the source buffer. 
>>>>>>
>>>>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>>>>
>>>>>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>>>>>> use ielm for that. Do you have suggestions ?
>>>>>
>>>>> The relevance of ielm is that it is a powerful and useful tool you have
>>>>> at hand when doing development or bug fixing in elisp. It provides the
>>>>> REPL where you can test/evaluate bits of code. How useful it is for a
>>>>> specific issue will depend on that issue. 
>>>>
>>>> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
>>>> interested to know if I can improve on my workflow. 
>>>>
>>>
>>> Evaluating sexp in the code is very valuable. However, sometimes, I just
>> What do you mean in the code? Like C-x C-e?
>>
>> M-: opens a repl, similar to ielm. It places cursor in minibuffer and
>> lets me eval a function with any arguments and so. Ielm asks me to keep
>> a prompt open in another buffer. So I have to switch to and from that
>> buffer, so I never really appreciate it. So I wonder if ielm has
>> something more to offer, than what I get from M-:?
>>
>
> M-: isn't what I would call a REPL. It just provides a way to evaluate a
> lisp expression which you can enter in the echo area. It is similar to
> eval-last-sexp (C-x C-e), except as you say, you can specify the arguments.
>
> Where ielm differs is that it is more like a proper REPL - it adds the
> 'L' (loop) which you don't have with M-:, which is really just the REP
> (read, eval print) part. With ielm you can enter multiple statements, go back
> through history and edit/modify an expression and re-evaluate it. Define
> a new function and then call it, set a variable and then see its printed
> form by just typing it at the prompt etc. I also find it a lot easier
> when entering more complex expressions than just using the minibuffer
> with M-:.
>
> When I'm writing new eilsp, I will often open a new *.el file and a ielm
> buffer. I might write the first pass of a function in ielm, run it with
> different arguments until it works as desired and then copy it back to
> the *.el file to save it.
>
> I don't find it an issue to switch buffers - this is what I'm doing all
> the time. I have a frame with multiple tabs and each tab might have
> multiple windows and I will jump around between them constantly. It only
> takes one or two key strokes, so I find it no more hassle than M-:.
>
> Being able to edit more complex expressions and move up/down through the
> history is extremely useful. However, I also really enjoy interactive
> development and exploration. I hate writing a whole heap of code and
> then having to spend hours debugging it. I prefer to write small
> functions and build them up bit by bit, running and testing them as I
> go. For this, ielm is a key tool. 
>
> What would be even better is the ability to send code from the buffer to
> be evaluated in the ielm buffer. I think Stefan posted something about
> this recently. This could make it easier to execute expressions within a
> context you have created and provide some additional functionality which
> isn't easily done now (though of course, being Emacs, you can set it up).
>
> To what extent you would find ielm useful really depends on personal taste
> and style when it comes to development and/or debugging. This is both
> the power and weakness of Emacs. It is powerful because you can create
> the workflow which is more natural and customised to individual tastes.
> It is a weakness because 'out of the box', things are very vanilla and
> it can take time to learn what is possible and configure it. To be
> honest, my current emacs lisp environment is nowhere as refined and
> configured as it once was. Back when I was doing more elisp, things were
> heavily customised with many advanced features enabled, custom key
> bindings, additional functions, advice etc etc. However, I rarely find
> it necessary to do much elisp these days. I've even stopped maintaining
> my own emacs configuration and now just use spacemacs - I have always
> liked VI's modal editing style and I find spacemacs mostly works really
> well. I have some fairly minor tweaks and customisation, but on the
> whole, I just leave it alone and get on with the other stuff I need to
> do. 
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Emacs development...

[Eric Abrahamsen]

"T.V Raman" <raman@google.com> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>
> In addition to all you say below re IELM, the nugget of gold that makes
> it invaluable is its ability to  set the eval context buffer while
> remaining in the ielm buffer, see command bound to C-c b.

Hey, that's great! I'd also been on the fence about the value of IELM
over the plain old *scratch* buffer, and that's a real advantage.

To muddy the waters further, there's also the "emacs inspector"[1] which
provides another way of looking at objects and symbols. It doesn't help
with the original query about watching values change during execution,
though.

[1]: https://github.com/mmontone/emacs-inspector

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 23, 2021, at 1:04, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> 
> "T.V Raman" <raman@google.com> writes:
> 
>> Tim Cross <theophilusx@gmail.com> writes:
>> 
>> 
>> In addition to all you say below re IELM, the nugget of gold that makes
>> it invaluable is its ability to  set the eval context buffer while
>> remaining in the ielm buffer, see command bound to C-c b.
> 
> Hey, that's great! I'd also been on the fence about the value of IELM
> over the plain old *scratch* buffer, and that's a real advantage.
> 
> To muddy the waters further, there's also the "emacs inspector"[1] which
> provides another way of looking at objects and symbols. It doesn't help
> with the original query about watching values change during execution,
> though.

But that makes me think that, I could possibly load package.el in ielm and run it from there, couldn't I ? And I'd have all the values right at hand, not quite like edebug I guess, but I could actually check their value inside ielm, right ?

> [1]: https://github.com/mmontone/emacs-inspector

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Eric Abrahamsen]

On 08/23/21 01:19 AM, Jean-Christophe Helary wrote:
>> On Aug 23, 2021, at 1:04, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> 
>> "T.V Raman" <raman@google.com> writes:
>> 
>>> Tim Cross <theophilusx@gmail.com> writes:
>>> 
>>> 
>>> In addition to all you say below re IELM, the nugget of gold that makes
>>> it invaluable is its ability to  set the eval context buffer while
>>> remaining in the ielm buffer, see command bound to C-c b.
>> 
>> Hey, that's great! I'd also been on the fence about the value of IELM
>> over the plain old *scratch* buffer, and that's a real advantage.
>> 
>> To muddy the waters further, there's also the "emacs inspector"[1] which
>> provides another way of looking at objects and symbols. It doesn't help
>> with the original query about watching values change during execution,
>> though.
>
> But that makes me think that, I could possibly load package.el in ielm
> and run it from there, couldn't I ? And I'd have all the values right
> at hand, not quite like edebug I guess, but I could actually check
> their value inside ielm, right ?

Having only just learned about this feature, I'm not sure! But it
certainly sounds like you could set package.el as your "working" buffer
and operate there. Except that (depending on what it is you're
debugging) you might actually want to set *Packages* as your working
buffer, assuming that that's where the action is happening.

Re: Emacs development...

[Arthur Miller]

Jean-Christophe Helary <lists@traduction-libre.org> writes:

>> On Aug 23, 2021, at 1:04, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> 
>> "T.V Raman" <raman@google.com> writes:
>> 
>>> Tim Cross <theophilusx@gmail.com> writes:
>>> 
>>> 
>>> In addition to all you say below re IELM, the nugget of gold that makes
>>> it invaluable is its ability to  set the eval context buffer while
>>> remaining in the ielm buffer, see command bound to C-c b.
>> 
>> Hey, that's great! I'd also been on the fence about the value of IELM
>> over the plain old *scratch* buffer, and that's a real advantage.
>> 
>> To muddy the waters further, there's also the "emacs inspector"[1] which
>> provides another way of looking at objects and symbols. It doesn't help
>> with the original query about watching values change during execution,
>> though.
>
> But that makes me think that, I could possibly load package.el in ielm and run
> it from there, couldn't I ? And I'd have all the values right at hand, not quite

How will you load a buffer that is not an elisp file?

> like edebug I guess, but I could actually check their value inside ielm, right ?
>
>> [1]: https://github.com/mmontone/emacs-inspector

Re: Emacs development...

[Jean-Christophe Helary]

> On Aug 23, 2021, at 1:25, Arthur Miller <arthur.miller@live.com> wrote:
> 
>> But that makes me think that, I could possibly load package.el in ielm and run
>> it from there, couldn't I ? And I'd have all the values right at hand, not quite
> 
> How will you load a buffer that is not an elisp file?

package.el *is* an elisp file.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: Emacs development...

[Arthur Miller]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> "T.V Raman" <raman@google.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>
>> In addition to all you say below re IELM, the nugget of gold that makes
>> it invaluable is its ability to  set the eval context buffer while
>> remaining in the ielm buffer, see command bound to C-c b.
I see to missed that one. Yes that sounds useful.

> Hey, that's great! I'd also been on the fence about the value of IELM
> over the plain old *scratch* buffer, and that's a real advantage.
No, scratch buffer is not an alternative for development, in my opinion.

Re: Emacs development...

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1010 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:


ielm has been particularly useful when developing some of the more
esoteric parts of Emacspeak:-)
> "T.V Raman" <raman@google.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>
>> In addition to all you say below re IELM, the nugget of gold that makes
>> it invaluable is its ability to  set the eval context buffer while
>> remaining in the ielm buffer, see command bound to C-c b.
>
> Hey, that's great! I'd also been on the fence about the value of IELM
> over the plain old *scratch* buffer, and that's a real advantage.
>
> To muddy the waters further, there's also the "emacs inspector"[1] which
> provides another way of looking at objects and symbols. It doesn't help
> with the original query about watching values change during execution,
> though.
>
> [1]: https://github.com/mmontone/emacs-inspector
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Emacs development...

[Arthur Miller]

"T.V Raman" <raman@google.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>
> ielm has been particularly useful when developing some of the more
> esoteric parts of Emacspeak:-)
Hmmm, my ielm does not come with C-c b predefined. What is the name of
function it is bound to?

Re: Emacs development...

[Stephen Berman]

On Sun, 22 Aug 2021 19:44:29 +0200 Arthur Miller <arthur.miller@live.com> wrote:

> "T.V Raman" <raman@google.com> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>
>> ielm has been particularly useful when developing some of the more
>> esoteric parts of Emacspeak:-)
> Hmmm, my ielm does not come with C-c b predefined. What is the name of
> function it is bound to?

It would be very naughty of ielm to use `C-c b'.  `But C-h m' in the
*ielm* buffer shows this:

  The current working buffer may be changed (with a call to ‘set-buffer’,
  or with C-c C-b), and its value is preserved between successive
  evaluations.  In this way, expressions may be evaluated in a different
  buffer than the *ielm* buffer.  By default, its name is shown on the
  mode line; you can always display it with C-c C-v, or the buffer itself
  with C-c C-f.

Steve Berman

Re: Emacs development...

[Arthur Miller]

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sun, 22 Aug 2021 19:44:29 +0200 Arthur Miller <arthur.miller@live.com> wrote:
>
>> "T.V Raman" <raman@google.com> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>
>>> ielm has been particularly useful when developing some of the more
>>> esoteric parts of Emacspeak:-)
>> Hmmm, my ielm does not come with C-c b predefined. What is the name of
>> function it is bound to?
>
> It would be very naughty of ielm to use `C-c b'.  `But C-h m' in the
> *ielm* buffer shows this:
>
>   The current working buffer may be changed (with a call to ‘set-buffer’,
>   or with C-c C-b), and its value is preserved between successive
>   evaluations.  In this way, expressions may be evaluated in a different
>   buffer than the *ielm* buffer.  By default, its name is shown on the
>   mode line; you can always display it with C-c C-v, or the buffer itself
>   with C-c C-f.

Cool, thanks!

Re: Emacs development...

[Arthur Miller]

Arthur Miller <arthur.miller@live.com> writes:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 22 Aug 2021 19:44:29 +0200 Arthur Miller <arthur.miller@live.com> wrote:
>>
>>> "T.V Raman" <raman@google.com> writes:
>>>
>>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>>
>>>>
>>>> ielm has been particularly useful when developing some of the more
>>>> esoteric parts of Emacspeak:-)
>>> Hmmm, my ielm does not come with C-c b predefined. What is the name of
>>> function it is bound to?
>>
>> It would be very naughty of ielm to use `C-c b'.  `But C-h m' in the
>> *ielm* buffer shows this:
>>
>>   The current working buffer may be changed (with a call to ‘set-buffer’,
>>   or with C-c C-b), and its value is preserved between successive
>>   evaluations.  In this way, expressions may be evaluated in a different
>>   buffer than the *ielm* buffer.  By default, its name is shown on the
>>   mode line; you can always display it with C-c C-v, or the buffer itself
>>   with C-c C-f.
>
> Cool, thanks!

I have tested ielm a bit more now, and I definitely see the appeal. The
idea of working buffer is definitely a killer feature of ielm,
especially when one does not work with elisp buffers.

Yes it is more handy then M-: or M-x for testing the code.

Thanks.

Re: Emacs development...

[Arthur Miller]

Tim Cross <theophilusx@gmail.com> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> Arthur Miller <arthur.miller@live.com> writes:
>>>
>>>> Tim Cross <theophilusx@gmail.com> writes:
>>>>
>>>>> Jean-Christophe Helary <lists@traduction-libre.org> writes:
>>>>>
>>>>>>> On Aug 21, 2021, at 23:08, Tim Cross <theophilusx@gmail.com> wrote:
>>>>>>> 
>>>>>>> I would also recommend getting comfortable with ielm (M-x ielm), an
>>>>>>> Interactive Emacs Lisp Mode, as well as learning how to evaluate
>>>>>>> expressions in the source buffer. 
>>>>>>
>>>>>> Thank you Tim for the suggestion. I like ielm a lot, when I use it.
>>>>>>
>>>>>> What I am trying to do now is fix a bug in package.el and I don't see how I can
>>>>>> use ielm for that. Do you have suggestions ?
>>>>>
>>>>> The relevance of ielm is that it is a powerful and useful tool you have
>>>>> at hand when doing development or bug fixing in elisp. It provides the
>>>>> REPL where you can test/evaluate bits of code. How useful it is for a
>>>>> specific issue will depend on that issue. 
>>>>
>>>> What does ielm offer over M-: (eval-expression)? I use a lot M-: so I am
>>>> interested to know if I can improve on my workflow. 
>>>>
>>>
>>> Evaluating sexp in the code is very valuable. However, sometimes, I just
>> What do you mean in the code? Like C-x C-e?
>>
>> M-: opens a repl, similar to ielm. It places cursor in minibuffer and
>> lets me eval a function with any arguments and so. Ielm asks me to keep
>> a prompt open in another buffer. So I have to switch to and from that
>> buffer, so I never really appreciate it. So I wonder if ielm has
>> something more to offer, than what I get from M-:?
>>
>
> M-: isn't what I would call a REPL. It just provides a way to evaluate a
> lisp expression which you can enter in the echo area. It is similar to
> eval-last-sexp (C-x C-e), except as you say, you can specify the arguments.
> Where ielm differs is that it is more like a proper REPL - it adds the
> 'L' (loop) which you don't have with M-:, which is really just the REP
> (read, eval print) part. 
Isn't that what a repl is too? You type a form and press enter to get it
evaled in ielm. That is similar to eval-last-sexp, it is just that as
you say, one press <enter> instead of C-x C-e. I think both are
interfaces into emacs command loop, which is the real repl going on. I
don't know, I experience M-: as a hidden repl which is out of my way
until I needed while ielm asks me to have that repl open all the time in
a buffer. I don't say you are wrong, I just never really got into why I
should use ielm, and many are praising it, so I have a feel I am missing
something good :). 

>                          With ielm you can enter multiple statements, go back
> through history and edit/modify an expression and re-evaluate it. Define
> a new function and then call it, set a variable and then see its printed
> form by just typing it at the prompt etc.
But  you can do all that with M-:. It remembers history, you can go back
and forth and so. Results and printed forms, are echoed in the
minibuffer, and I usually open messages buffer.

There might you have the point: you don't need messages buffer with
ielm. Ielm displays everything in same buffer. I am so used to messages
buffer that I don't even thing of it. I have it almost always open. But
I don't switch to it, it is scrolling itself, and it is just "read only"
for me to see results from M-:. 

> When I'm writing new eilsp, I will often open a new *.el file and a ielm
> buffer. I might write the first pass of a function in ielm, run it with
> different arguments until it works as desired and then copy it back to
> the *.el file to save it.

We all have personal workflow, I am not sure that one would be for me. I
have those few shortcuts I posted in some comment before. I type in .el
file and than I can eval any form, from entire defun to just variable
directly with a shortcut. I understand appeal with a freshly written
defun, and than when you press enter, you are ready to type some test to
test how it works, while I have to hit M-: first to test it. But can you
easily change defun, say you need to fix a typo in the middle of a
defun? How do you do that in ielm? Can you just go back in buffer and
retupe and re-eval? I never tried to be honest. I am so used that I can
move freely in .el buffer, and when I type M-: and it finishes, my
corsor is back at same spot so I can fix typos, change defun etc. I
don't even need to jump to the end of defun to test it again. Is it one
of those things thay call trade offs? Both have trade off, and it's
personal preferance which one to go for?

Sorry, I dont' mean to compete, I am just really curious myself. I
dislike constant switching between buffers, contexts and so. I would
just like to type code as I type prosa. I even dislike special
characters like #$[] and such since they are not as easy to type on the
keyboard. I like to use macros so I don't need to quote stuff :-).

> I don't find it an issue to switch buffers - this is what I'm doing all
> the time. I have a frame with multiple tabs and each tab might have
> multiple windows and I will jump around between them constantly. It only
> takes one or two key strokes, so I find it no more hassle than M-:.
>
> Being able to edit more complex expressions and move up/down through the
> history is extremely useful. However, I also really enjoy interactive
> development and exploration. I hate writing a whole heap of code and
> then having to spend hours debugging it. I prefer to write small
> functions and build them up bit by bit, running and testing them as I
> go. For this, ielm is a key tool. 
Yes, that is me too. Regardless of a language. I prefer to write small
piece of code, small units. I would usually start by defining a function
and return points so I can compile it and run, than I would add a pice
of logic, like maybe a loop, or call to something else and compile
again, if possible run and so on. Unfortuantely does not scale well in
big code bases, complex guis and so. Not even when working with Emacs
C sorces, at least I didn't found a good way. But it works fine for
elisp.

> What would be even better is the ability to send code from the buffer to
> be evaluated in the ielm buffer. I think Stefan posted something about
> this recently. This could make it easier to execute expressions within a
> context you have created and provide some additional functionality which
> isn't easily done now (though of course, being Emacs, you can set it up).
I am not sure I follow about that "with the context I created", why not
just execute it in the context itself, why sending everything somewhere
else? Maybe I am missing something there. But I am really intersted to
hear bout which functionality more?

> To what extent you would find ielm useful really depends on personal taste
> and style when it comes to development and/or debugging. This is both
> the power and weakness of Emacs. 
Yes of course, I completely agree there. Seems lilke I have centered my
workflow around different tools and am little lazy to explore other
tools. That is why I ask you, since you seem to be using ielm :-). I am
very thankful for thorough explanations. Kind of you to explain it so
detailed.

> the workflow which is more natural and customised to individual tastes.
> It is a weakness because 'out of the box', things are very vanilla and
> it can take time to learn what is possible and configure it. To be
> honest, my current emacs lisp environment is nowhere as refined and
> configured as it once was. Back when I was doing more elisp, things were
> heavily customised with many advanced features enabled, custom key
> bindings, additional functions, advice etc etc. However, I rarely find
> it necessary to do much elisp these days. I've even stopped maintaining
> my own emacs configuration and now just use spacemacs - I have always
> liked VI's modal editing style and I find spacemacs mostly works really
> well. I have some fairly minor tweaks and customisation, but on the
> whole, I just leave it alone and get on with the other stuff I need to
> do. 
I find myself pressing lots of C-x and C-z, so I lately have being
thinking of how to lessen typing, and I think I like the idea used in
Vi, of having a "command mode" as normal and insert mode as editing
mode. But I have tried evil, and I can't really get that with 5
different modes and so. I also experienced some slugishness after evil
was on for a while. Maybe just mine config and me not being experienced
with evil. No Doom or Spacemacs here, just plain evil mode
installed. But I do like the idea with repeaters. I had thought for a
couple of monts to build a mode where I can press a key and have it
"sticky" until I turn it off. I think it is similar to idea of
mode. Someone on Reddit published yesterday a mode for just that, so
I don't need to build it myself now :-).

Re: Emacs development...

[Arthur Miller]

Konstantin Kharlamov <hi-angel@yandex.ru> writes:

> On Sat, 2021-08-21 at 16:50 +0900, Jean-Christophe Helary wrote:
>> 
>> 
>> > On Aug 21, 2021, at 16:16, Tassilo Horn <tsdh@gnu.org> wrote:
>> > 
>> > Jean-Christophe Helary <lists@traduction-libre.org> writes:
>> > 
>> > Hi Jean-Christophe,
>> > 
>> > > Right now, I use C-h f to find the function definitions and move
>> > > around the code.
>> > 
>> > That, and also M-. on a function call or variable will bring you to its
>> > definition.
>> 
>> Thank you.
>> 
>> Sorry for this very basic question, what's the best way to navigate back to
>> where I was ?
>
> Seems to me, you don't have a workflow yet for development in general through
> Emacs. Because questions like "how to go to definition" and "how to go back"
> aren't really specific to ELisp, it's something you'd use while working with
> pretty much any language, be it C, Python, Haskell, C++, Rust… The only question
> you asked specific to ELisp is about debugging ELisp code.
>
> This is okay ofc, I'm just pointing it out because it might give you some ideas on what to look for.
>
> There's a popular opinion that default Emacs keybindings aren't the best, and people usually reconfigure some of them as they find appropriate.
>
> And there're many different workflows for code/text navigation in Emacs. For
> example, I personally prefer using Evil plugin (a vim-mode inside Emacs, but it
> actually had more features than the actual vim), and using C-o, C-i in "normal
> mode" of Evil to go back and forth between locations in text. By default it may
> switch buffers which I don't like, so I disabled that. "going to definition" I
> personally bound to "gd" in normal mode of Evil. And then, inside a single file
> there are usually multiple specific places that are of interest to me, so I set
> marks to them with (again, keybinding specific to Evil) "m1", "m2", "m3"…
> i.e. just enumerating them in an order I find interesting.
>
> There's also "avy" package for faster navigation within the visible text portions.
>
> There are also Emacs "starter-kits" with lots of preconfigured stuff, e.g. Doom
> Emacs I heard is very good (I never personally used it, because by the time it
> became popular I already had a personalized configuration, however people seem
> to like it).
>
> So, yeah, for things non-specific to ELisp development (which is so far was
> everything you mentioned except ELisp debugging), you just need to start trying
> to do the development, and along the way to try to reflect "what I really wish I
> was able to do right now". Stuff like autocompletion, seeing function help in a
> minibuffer or elsewhere, going to definition… Whatever you think of, it is
> probably implemented in Emacs (with or without plugins), so you just try to
> search for it using your favorite search engine.

Another not-so-elisp-specific thing would be to learn how to use a
debugger.

He could also take a class of computer science, or an online course etc
:).

Otherwise for non mentioned tips yet, structure editing cal also be
helpful (paredit/smartparens/lispy). Lispy is very good for elisp 
development.

Also a remapping some of hard to hit key combos predefined by Emacs, and
addign few trivial defs on top, for me makes a difference when evaluating
stuff. I have these following few small helpers:

#+begin_src emacs-lisp

;; From: https://emacs.wordpress.com/2007/01/17/eval-and-replace-anywhere/
(defun fc-eval-and-replace ()
  "Replace the preceding sexp with its value."
  (interactive)
  (backward-kill-sexp)
  (condition-case nil
      (prin1 (eval (read (current-kill 0)))
             (current-buffer))
    (error (message "Invalid expression")
           (insert (current-kill 0)))))

;; https://stackoverflow.com/questions/2171890/emacs-how-to-evaluate-the-smallest-s-expression-the-cursor-is-in-or-the-follow
(defun eval-next-sexp ()
  (interactive)
  (save-excursion
    (forward-sexp)
    (eval-last-sexp nil)))

;; this works sometimes
(defun eval-surrounding-sexp (levels)
  (interactive "p")
  (save-excursion
    (up-list (abs levels))
    (eval-last-sexp nil)))

(require 'popup)

(defun describe-thing-in-popup ()
  (interactive)
  (let* ((thing (symbol-at-point))
         (help-xref-following t)
         (description
          (save-window-excursion
            (with-temp-buffer
              (help-mode)
              (describe-symbol thing)
              (buffer-string)))))
    (popup-tip description
               :point (point)
               :around t
               :height 30
               :scroll-bar t
               :margin t)))

(defun value-at-point-in-popup ()
  (interactive)
  (let* ((thing (symbol-at-point))
         (value (and (boundp thing) (symbol-value thing))))
    (popup-tip (format "%s" value)
               :point (point)
               :around t
               :height 30
               :scroll-bar t
               :margin t)))

(defun last-sexp-in-popup ()
  (interactive)
  (let* ((value (eval-last-sexp nil)))
    (popup-tip (format "%s" value)
               :point (point)
               :around t
               :height 30
               :scroll-bar t
               :margin t)))

(defun next-sexp-in-popup ()
  (interactive)
  (let* ((value (eval-next-sexp)))
    (popup-tip (format "%s" value)
               :point (point)
               :around t
               :height 30
               :scroll-bar t
               :margin t)))

(defun surrounding-sexp-in-popup ()
  (interactive)
  (let* ((value (eval-surrounding-sexp 1)))
    (popup-tip (format "%s" value)
               :point (point)
               :around t
               :height 30
               :scroll-bar t
               :margin t)))

#+end_src

And I bind those like this:

#+begin_src emacs-lisp

(defkeys emacs-lisp-mode-map
"\C-c a" emacs-lisp-byte-compile-and-load
"\C-c b" emacs-lisp-byte-compile
"\C-c c" emacs-lisp-native-compile-and-load
"\C-c d" eval-defun
"\C-c e" eval-buffer
"\C-c i" reindent-buffer
"\C-c l" eval-last-sexp
"\C-c n" eval-next-sexp
"\C-c r" fc-eval-and-replace
"\C-c s" eval-surrounding-sexp)

#+end_src

So I can (often) just place my cursor somewhere in, before or after an
expression and eval it, as well as an expression before or after. It
reduces somewhat movements with cursor. For example I can place cursor
between a defun and a test for defun and eval prev/nect without moving
cursor etc. These are small trivial helpers, but I find them quite
useful sometimes.

Eldoc is also good to have when working with elisp.

Re: Emacs development...

[Eli Zaretskii]

> From: Jean-Christophe Helary <lists@traduction-libre.org>
> Date: Sat, 21 Aug 2021 16:08:54 +0900
> Cc: emacs-devel@gnu.org
> 
> But when I run package.el to test it, I'd like to have a way to examine the values of variables as they evolve. Right now I use message and check the *Messages* buffer... It is not ideal.
> 
> And there are probably a few other things that would make work easier but that I am not aware of because I am not a developer.

The other alternative is Edebug, I think.  You instrument the function
where the variables in which you are interested live, then evaluate
their values while stepping through that function (if Edebug didn't
evaluate them automatically for you).

Re: Emacs development...

[Alfred M. Szmidt]

   For ex. is there a way to see the values of variables as I run the
   code, so that I don't need to modify the values of "message" here
   and there to have clues ?

If it wasn't mentioned, you can also use the trace-function function
to trace functions.