RE: question

RE: question

[Drew Adams]

emacs-devel@gnu.org is the Emacs-developer mailing list, and help-gnu-emacs@gnu.org is a mailing list for asking questions about Emacs. (bug-gnu-emacs@gnu.org is only for reporting and discussing Emacs bugs.)

I'm cc'ing emacs-devel. I'm sure Emacs developers will welcome your help. And your English is fine, BTW.

    I present myself. I have finished the Faculty of Mathematics, 
    and now I study the Informatics in Bucarest. I wish to become a 
    developer of Emacs, and I do not find any starting point. I 
    speak French very well... I do not speak English well...
    
    I would be very pleased if somebody could give me some 
    references/indications where I start from... I lookes on emacs 
    wiki's page, but nothing clear.
    
    Thanks in advance. Alin Soare

RE: question

[A Soare]

Thanks,

I wish to become specialist in Emacs LISP.

I am looking forward to start with something.

I want to implicate myself as soon as possible, not only because I like Emacs and lisp and want to become specialist in these ones, but, in plus, because I wish to dedicate some fine work to an old friend girl of mine depuis les banlieues de Rouen, France, too.

Could you send me a problem (bug or another problem kind), please? Or something to start from...

I am beginner, but I wish very much to implicate in emacs, so you can send me not necessary an easy problem... to think to and solve it.

Thanks,

A Soare

PS: I will to dedicate my time when I do not study a great course of french civilisation, and when I do not work on some courses of informatics from Institute of Mathematics of the Romanian Academy of Sciences (IMAR) or to my job.



> Message du 28/07/06 à 21h39
> De : "Drew Adams" <drew.adams@oracle.com>
> A : alinsoar@voila.fr, bug-gnu-emacs@gnu.org
> Copie à : "Emacs-Devel" <emacs-devel@gnu.org>
> Objet : RE: question
> 
> emacs-devel@gnu.org is the Emacs-developer mailing list, and help-gnu-emacs@gnu.org is a mailing list for asking questions about Emacs. (bug-gnu-emacs@gnu.org is only for reporting and discussing Emacs bugs.)
> 
> I'm cc'ing emacs-devel. I'm sure Emacs developers will welcome your help. And your English is fine, BTW.
> 
>     I present myself. I have finished the Faculty of Mathematics, 
>     and now I study the Informatics in Bucarest. I wish to become a 
>     developer of Emacs, and I do not find any starting point. I 
>     speak French very well... I do not speak English well...
>     
>     I would be very pleased if somebody could give me some 
>     references/indications where I start from... I lookes on emacs 
>     wiki's page, but nothing clear.
>     
>     Thanks in advance. Alin Soare
> 
> 
>

Re: question

[David Kastrup]

A Soare <alinsoar@voila.fr> writes:

> Thanks,
>
> I wish to become specialist in Emacs LISP.
>
> I am looking forward to start with something.
>
> I want to implicate myself as soon as possible, not only because I
> like Emacs and lisp and want to become specialist in these ones,
> but, in plus, because I wish to dedicate some fine work to an old
> friend girl of mine depuis les banlieues de Rouen, France, too.
>
> Could you send me a problem (bug or another problem kind), please?
> Or something to start from...
>
> I am beginner, but I wish very much to implicate in emacs, so you
> can send me not necessary an easy problem... to think to and solve
> it.

The file admin/FOR-RELEASE in the Emacs CVS tree contains tasks to be
solved right now.  You might want to take a look at them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: question

[Nick Roberts]

 > > I am beginner, but I wish very much to implicate in emacs, so you
 > > can send me not necessary an easy problem... to think to and solve
 > > it.
 > 
 > The file admin/FOR-RELEASE in the Emacs CVS tree contains tasks to be
 > solved right now.  You might want to take a look at them.

Sure.  The ones that need a field expert are particularly suitable for a
beginner.  I just can't understand why they haven't already been fixed...


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: question

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > I am beginner, but I wish very much to implicate in emacs, so
>  > > you can send me not necessary an easy problem... to think to
>  > > and solve it.
>  > 
>  > The file admin/FOR-RELEASE in the Emacs CVS tree contains tasks
>  > to be solved right now.  You might want to take a look at them.
>
> Sure.  The ones that need a field expert are particularly suitable
> for a beginner.  I just can't understand why they haven't already
> been fixed...

Many of the remaining tasks involve proofreading.  They haven't been
done already because they are tedious and take time, in particular if
you check for accuracy by trying out things.

Did you actually take a look at FOR-RELEASE?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: question

[Thien-Thi Nguyen]

A Soare <alinsoar@voila.fr> writes:

> I wish to become specialist in Emacs LISP.
> 
> I am looking forward to start with something.

probably you can help yourself (and emacs as a by-product)
best by realizing that you already are a specialist (at something
outside of emacs).  as you apply your specialty to improving emacs,
you will most likely find yourself becoming a generalist, and the
tool for that transformation, emacs lisp.

wrt hacking emacs to impress a third party, i can suggest you
play w/ M-x zone -- its performance can be improved in addition
to its depth and range of esthetic expression.  moreover, the
results can be appreciated by non-programmer emacs users.

in my case:

 acquaintance -> zone.el hacking / courtship -> marriage

(a bit simplified, you understand... ;-)

good luck in your search!

thi

Re: question

[Richard Stallman]

There are two files in the Lisp manual that need a second check.
Could you do them?

Question

[Carsten Dominik]

Hi everyone,

I am on the verge to install a new version of Org mode into the Emacs  
tree.
This version includes org-babel, a system to work with source code
snippets embedded in files, for documentation purposes, but also
for evaluating them in a reproducible research way.

For supporting different languages, we will have a few emacs lisp
files which should not be compiled because the have dependencies on
code that is not present in Emacs.  I.e. they do something like

    (require 'slime)

and call lots of functions from this package.

I think the best way it to leave these files
uncompiled.  Is this acceptable?  If yes, how do
I exclude them from compilation in the standard
Emacs build process.

How would I do this?


- Carsten

Re: Question

[Juanma Barranquero]

On Fri, Jul 2, 2010 at 06:15, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> For supporting different languages, we will have a few emacs lisp
> files which should not be compiled because the have dependencies on
> code that is not present in Emacs.  I.e. they do something like
>
>   (require 'slime)
>
> and call lots of functions from this package.

Are these compile-time dependencies?

> I think the best way it to leave these files
> uncompiled.  Is this acceptable?

There are at least 82 .el files in lisp/** than are not compiled.

> If yes, how do
> I exclude them from compilation in the standard
> Emacs build process.

If you just want for the files not being byte-compiled, you can use

  -*- no-byte-compile: t -*-

or

  ;; Local Variables:
  ;; no-byte-compile: t
  ;; End:

but, are these packages usable when non-compiled? Because if they're
not, they should simply be excluded from the Emacs tree, I think.

    Juanma

Re: Question

[Lennart Borgman]

On Fri, Jul 2, 2010 at 6:15 AM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> Hi everyone,
>
> I am on the verge to install a new version of Org mode into the Emacs tree.
> This version includes org-babel, a system to work with source code
> snippets embedded in files, for documentation purposes, but also
> for evaluating them in a reproducible research way.
>
> For supporting different languages, we will have a few emacs lisp
> files which should not be compiled because the have dependencies on
> code that is not present in Emacs.  I.e. they do something like
>
>   (require 'slime)
>
> and call lots of functions from this package.
>
> I think the best way it to leave these files
> uncompiled.  Is this acceptable?  If yes, how do
> I exclude them from compilation in the standard
> Emacs build process.

Why not use (require 'slime nil t)?

Question

[Stephen J. Turnbull]

Carsten Dominik writes:

 > For supporting different languages, we will have a few emacs lisp
 > files which should not be compiled because the have dependencies on
 > code that is not present in Emacs.  I.e. they do something like
 > 
 >     (require 'slime)

This is not a problem, unless it's within `eval-when-compile'.  Go
ahead and compile it otherwise.

 > and call lots of functions from this package.

For *functions*, this isn't a problem, either.  However, *macros* from
the slime library must be defined at compile time, because Emacs byte
code doesn't know how to expand and reevaluate macros.  (IIRC, anyway,
for sure XEmacs's bytecode interpreter can't do that.)  Instead, the
macro is expanded, then the expansion is compiled at compile time.

 > I think the best way it to leave these files uncompiled.

I feel sick ... ok, it got better.  No, this is rarely a good idea.
If you have only functions, it's pointless.  If you have macros, then
remember that macros get evaluated twice: once to generate code, and
once to evaluate the generated code.  The function that generates the
expansion is rarely very efficient because it is expected to be
expanded once at compile time.  Instead it is normally written to be
as straightforward an expression of the desired expansion code as
possible.  IOW, you're likely to impose a perceptible performance hit
on those users.

Since org-mode is now part of Emacs, third party packages can assume
it will be available, and if leaving files uncompiled seems your only
option, then it's probably best all-around to contribute that code to
the third-party package, and have it compiled there.

Re: Question

[Richard Stallman]

    For supporting different languages, we will have a few emacs lisp
    files which should not be compiled because the have dependencies on
    code that is not present in Emacs.  I.e. they do something like

	(require 'slime)

Please don't install any files that depend on code not in Emacs.

(Why is that code not in Emacs?  Have people already considered
whether to install it?)

Re: Question

[Carsten Dominik]

OK, thanks for the input everyone.

We'll think about and implement appropriate solutions.
Looking at the files again, I actually think that we can make
them compile with a small number of declare-function statements.

Thanks!

- Carsten

On Jul 2, 2010, at 1:45 PM, Stephen J. Turnbull wrote:

> Carsten Dominik writes:
>
>> For supporting different languages, we will have a few emacs lisp
>> files which should not be compiled because the have dependencies on
>> code that is not present in Emacs.  I.e. they do something like
>>
>>    (require 'slime)
>
> This is not a problem, unless it's within `eval-when-compile'.  Go
> ahead and compile it otherwise.
>
>> and call lots of functions from this package.
>
> For *functions*, this isn't a problem, either.  However, *macros* from
> the slime library must be defined at compile time, because Emacs byte
> code doesn't know how to expand and reevaluate macros.  (IIRC, anyway,
> for sure XEmacs's bytecode interpreter can't do that.)  Instead, the
> macro is expanded, then the expansion is compiled at compile time.
>
>> I think the best way it to leave these files uncompiled.
>
> I feel sick ... ok, it got better.  No, this is rarely a good idea.
> If you have only functions, it's pointless.  If you have macros, then
> remember that macros get evaluated twice: once to generate code, and
> once to evaluate the generated code.  The function that generates the
> expansion is rarely very efficient because it is expected to be
> expanded once at compile time.  Instead it is normally written to be
> as straightforward an expression of the desired expansion code as
> possible.  IOW, you're likely to impose a perceptible performance hit
> on those users.
>
> Since org-mode is now part of Emacs, third party packages can assume
> it will be available, and if leaving files uncompiled seems your only
> option, then it's probably best all-around to contribute that code to
> the third-party package, and have it compiled there.
>

Question

[Ergus]

Hi:

I am not proposing anything just making a question:

Why, if we have imenu (which looks better than the list-buffers), it is
not the default for C-x C-b?

I know it is just a line in the config, but for example when loading
with emacs -Q will be available by default and have a most modern view.

Is it a reason for that or just the typical disagree about defaults?

Re: Question about ibuffer

[Ergus]

On Sun, Nov 10, 2019 at 04:14:22AM +0100, Ergus wrote:
>Hi:
>
>I am not proposing anything just making a question:
>
>Why, if we have imenu (which looks better than the list-buffers), it is
>not the default for C-x C-b?
>
>I know it is just a line in the config, but for example when loading
>with emacs -Q will be available by default and have a most modern view.
>
>Is it a reason for that or just the typical disagree about defaults?

Sorry I mean ibuffer my bad.

Re: Question

[Stefan Monnier]

> Why, if we have ibuffer (which looks better than the list-buffers), it is
> not the default for C-x C-b?

Because list-buffers was there (long) before and ibuffer is not a simple
drop in replacement (it has a different UI, for one, and I'm not
completely sure that it is a strict superset w.r.t features).

It's a long standing problem, indeed.


        Stefan

Re: Question

[Andreas Schwab]

On Nov 10 2019, Ergus wrote:

> Why, if we have imenu (which looks better than the list-buffers)

Does it?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Question

[João Távora]

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

On Sun, Nov 10, 2019, 08:08 Andreas Schwab <schwab@linux-m68k.org> wrote:

> On Nov 10 2019, Ergus wrote:
>
> > Why, if we have imenu (which looks better than the list-buffers)
>
> Does it?
>

If Ergus meant ibuffer, then yes it does. Though looks aren't everything
and the UI could be revised slightly to work nicely for
non-ibuffer-power-users. Or to approach list-buffer's.

João

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

Re: Question about ibuffer

[Eli Zaretskii]

> Date: Sun, 10 Nov 2019 04:17:43 +0100
> From: Ergus <spacibba@aol.com>
> 
> >Why, if we have imenu (which looks better than the list-buffers), it is
> >not the default for C-x C-b?
> >
> >I know it is just a line in the config, but for example when loading
> >with emacs -Q will be available by default and have a most modern view.
> >
> >Is it a reason for that or just the typical disagree about defaults?
> 
> Sorry I mean ibuffer my bad.

I have C-x C-b rebound to a different command long ago (not to
ibuffer), and I don't really understand why we need to talk about
defaults that are so easy to change as the user sees fit.

If we do change the default in this case, we will need to adapt the
related documentation, including the tutorial and the user manual.

Re: Question about ibuffer

[Stefan Monnier]

> I have C-x C-b rebound to a different command long ago (not to
> ibuffer), and I don't really understand why we need to talk about
> defaults that are so easy to change as the user sees fit.

That's why I'd like to merge ibuffer and list-buffers: so we get
extended functionality without the user having to choose.

> If we do change the default in this case, we will need to adapt the
> related documentation, including the tutorial and the user manual.

A merge also won't require adapting the manual: only completing it with
the new functionality.


        Stefan