Re: ECB

Re: ECB

[Eric M. Ludlam]

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

Hi,

  I get emacs-devel as a digest.  Here is a reply to a few messages
  on the list.

>>> Kai Grossjohann <kai@emptydomain.de> wrote:
>> Could a couple of people please look at ECB, in http://ecb.sourceforge.net,
>> and tell me what you think of it?
>
>One difference between an IDE and Emacs is that IDEs often show
>various bits of information about the current project in little
>windows around the suorce code.  With ECB, Emacs can do the same
>thing.
>
>ECB is très cool.
>
>Note that ECB works with CEDET which provides parsing of source
>code.  This is a framework that has lots of potential for vastly
>improving Emacs' support for different programming languages.  What
>we can see in ECB is merely the tip of the iceberg.  I think that
>including CEDET in Emacs would enable various other packages to take
>advantage of it.  For example, font-lock could be improved by better
>parsing, as could syntactic indentation.  CEDET already provides
>syntax-driven completion: if x is a struct, then completing after
>"x." completes the members of that struct.
>
>CEDET is très cool.

Just as an FYI on CEDET, all of the individual tools in it have
already had papers signed for them and sent in.  I have to get
periodic papers from my employer and a set is currently wandering
through the legal department.

>>> Stefan <monnier@iro.umontreal.ca> wrote:
>> CEDET is très cool.
>
>Indeed.  But it needs to be made lazier and less global.
>Last time I tried to use JDE (which uses CEDET) it ended up taking a very
>significant time to open up an Elisp or a C file even though I only ever
>used CEDET-related operations on Java files.

I recall your email to me.  The current CVS version has since been
updated to delay parsing to an idle timer.  Tools that need the
buffer parsed now must wait until an idle timer goes off, so related
decorations don't show up till a few seconds after the buffer is
visible.  Your other request of disabling parsing for an individual
mode is still on my to-do list but it is unclear to me what to do
about it since all the load-time hooks are auto-generated in
auto-load files.

>>> From: Jason Rumney <jasonr@gnu.org>
>Kai Grossjohann <kai@emptydomain.de> writes:
>
>> And then, CEDET contains libraries and utilities that are used for
>> implementing the other packages.
>>
>> I hope that I have not misrepresented the CEDET functionality too
>> much.
>
>speedbar is also a part of CEDET. My understanding is that these
>tools originally started as seperate elisp libraries, but have grown
>dependant on each other and the author (Eric Ludlam <zappo@gnu.org>)
>has decided to release them as a single package in future.

This is indeed correct.  Releasing one tool often required a new
release of another with only one bug fix in it.  It was quite a
hassle.  Releasing them all at once has simplified things, but made
testing a bit more challenging.

Enjoy
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

Re: ECB

[Stefan]

> I recall your email to me.  The current CVS version has since been
> updated to delay parsing to an idle timer.  Tools that need the
> buffer parsed now must wait until an idle timer goes off, so related
> decorations don't show up till a few seconds after the buffer is
> visible.

Great to hear.

> Your other request of disabling parsing for an individual
> mode is still on my to-do list but it is unclear to me what to do
> about it since all the load-time hooks are auto-generated in
> auto-load files.

I'm not sure whether it should be on the todo list.  I think I mentioned it
more as a "this is so slow, please do *something*".  Other approaches such
as laziness are much better.

But if it's still deemed necessary, a way to "enable for a few specific
modes" would be more useful to me than a way to "disable for a few specific
modes".


        Stefan

Re: ECB

[Richard Stallman]

Could you tell us more about semantic?

For instance, is it written entirely in Emacs Lisp?
If not, what other languages are needed?  Does it use any
separate auxiliary programs?

Are you the author of semantic?
If not, could you tell me how to reach the author?
It seems very desirable to include semantic in Emacs.

Re[2]: ECB

[Eric M. Ludlam]

>>> Richard Stallman <rms@gnu.org> seems to think that:
>Could you tell us more about semantic?
>
>For instance, is it written entirely in Emacs Lisp?
>If not, what other languages are needed?  Does it use any
>separate auxiliary programs?
>
>Are you the author of semantic?
>If not, could you tell me how to reach the author?
>It seems very desirable to include semantic in Emacs.

Semantic, and those other libraries it depends on are all written
entirely in Emacs Lisp.  The doc uses makeinfo.  There are two shell
scripts which are optional that use bash.  The scripts allow creation
of data files by calling Emacs in batch mode.  There is a utility that
generates UML diagrams from source code that calls "dot" (released by
ATT as a graph diagram kind of tool.) which is optional.  There were
rumors of a tool for using PostgreSQL as a database backend but I have
not seen news of it lately.

I am the main author of Semantic and all the items not currently in
Emacs that it depends on.  David Ponce is also a primary contributor.
Paul Kinnucan (author of JDEE) wrote the original imenu support, but
there is very little left of his original work.  Klaus Berndl (ECB
author) wrote a regression test.  All other packages that represent
significant works beyond a small patch by other authors are separated
in a "contrib" directory.

A version of semantic from perhaps around the year 2000 is already
fully assigned to the FSF.  I have my paperwork submitted to my
Employer's legal department for clearance on those intervening years
so the current version can be a part of Emacs too.

Semantic depends on several small utilities written in Emacs Lisp by
either myself or David Ponce including tools for simplified Image
loading and use, progress bar display, runtime version dependency
checking, and an implementation of "mode local" variables/functions.

I highly recommend using mode-local.el.  I think it could greatly
simplify the construction of any tool that has slightly different
behaviors in different major modes, or the major modes themselves.
It eliminates the need for hooks or complex functions that contain
lots of `setq' calls, or functions that branch based on a alist of
major modes.

http://cvs.sourceforge.net/viewcvs.py/cedet/cedet/common/mode-local.el?view=markup

Semantic also depends on EIEIO which is a CLOS layer also previously
assigned to the FSF.  It too is in the CEDET collection.

You can read about all the tools in the CEDET collection at this web
site:

http://cedet.sourceforge.net

The CEDET package scheme and related Makefiles are merely a
convenience for releasing and building all those tools together.  The
Makefiles are generated by EDE, which adds project management and
Makefile construction with a nifty GUI inside Emacs.

The most complex part of the build is converting grammar files (.by,
or .wy) into Emacs Lisp.  This requires a calling Emacs in batch mode
with Semantic loaded to perform the generation.

Also involved is a special autoload file generator.  It is a copy of
the one that comes with Emacs and modified to handle CLOS constructs
and some Semantic macros.

I hope this answers your questions.
Eric

-- 
          Eric Ludlam:                 zappo@gnu.org, eric@siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

transparent emacs

[Nic Ferrier]

Has anyone thought about making Emacs transparent since Miles Bader
did some work on emacs 20?

I've been playing with GTK Emacs... I can make the background come up
in the content pane but I can't stop the background color on the
words.

Transparent Emacs would be so cool.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: transparent emacs

[Miles Bader]

On Sat, Aug 07, 2004 at 12:10:24AM +0100, Nic Ferrier wrote:
> Has anyone thought about making Emacs transparent since Miles Bader
> did some work on emacs 20?

Note that my current "transparent emacs" (really, "tiling") emacs branch is
kept up-to-date with the CVS trunk (more or less; last merge about 1 week
ago).

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: transparent emacs

[Nic Ferrier]

Miles Bader <miles@gnu.org> 
 writes:

> On Sat, Aug 07, 2004 at 12:10:24AM +0100, Nic Ferrier wrote:
> > Has anyone thought about making Emacs transparent since Miles Bader
> > did some work on emacs 20?
> 
> Note that my current "transparent emacs" (really, "tiling") emacs branch is
> kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> ago).

Is it still only in arch? Google didn't find an obvious working
download.


Nic

Re: transparent emacs

[Miles Bader]

On Sat, Aug 07, 2004 at 02:15:52AM +0100, Nic Ferrier wrote:
> > Note that my current "transparent emacs" (really, "tiling") emacs branch is
> > kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> > ago).
> 
> Is it still only in arch? Google didn't find an obvious working
> download.

Yes, but if you can't get arch to work for some reason, I can easily send you
a patch against a recent CVS emacs.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: transparent emacs

[Romain Francoise]

Miles Bader <miles@gnu.org> writes:

> Note that my current "transparent emacs" (really, "tiling") emacs branch is
> kept up-to-date with the CVS trunk (more or less; last merge about 1 week
> ago).

For the record, I'll mention that I use this Emacs branch and like the
feature very much.  It might not be the most essential thing in an
editor but having a good-looking Emacs environment is nice, and it
integrates well with other "transparent" applications. [1]

I do hope it will get merged in the main trunk along with multi-tty and
Unicode changes for Emacs 22.

Cheers,

-- 
Romain Francoise <romain@orebokech.com> | It's in your reach.
it's a miracle -- http://orebokech.com/ | Concentrate.

Footnotes:
[1] <URL: http://orebokech.com/my/shot_tiling.png>

GTK emacs (and access to GTK)

[Nic Ferrier]

I started to use GTK emacs a few months ago... Life was a bit busy so
I forgot to say "the GTK port of Emacs is brilliant!"

So I'm going to say it now:

The GTK port of Emacs is brilliant.

Well done to everybody involved in hacking it.


A related question: what are the views about allowing Emacs to create
GTK objects directly? 

I know it is generally frowned upon to export native window system
primitives into Emacs but because GTK is a GNU lib maybe there could
be an exception. 

William Perry already wrote some code for XEmacs which could maybe
serve as a guide?

  http://www.cs.indiana.edu/elisp/gui-xemacs/


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: GTK emacs (and access to GTK)

[David Kastrup]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I started to use GTK emacs a few months ago... Life was a bit busy so
> I forgot to say "the GTK port of Emacs is brilliant!"
>
> So I'm going to say it now:
>
> The GTK port of Emacs is brilliant.
>
> Well done to everybody involved in hacking it.

Well, I am missing an option to use Athena style scrollbars.
Actually, this is more a GTK shortcoming (that you can't just
configure Athena behavior for all GTK apps), but if I at least have
the option to override this at compile time of my most important
application, it would be a good consolation.

I'd prefer it if somebody implemented an Athena-behavior option for
GTK in general.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GTK emacs (and access to GTK)

[Jan D.]

David Kastrup wrote:
> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> 
> 
>>I started to use GTK emacs a few months ago... Life was a bit busy so
>>I forgot to say "the GTK port of Emacs is brilliant!"
>>
>>So I'm going to say it now:
>>
>>The GTK port of Emacs is brilliant.
>>
>>Well done to everybody involved in hacking it.
> 
> 
> Well, I am missing an option to use Athena style scrollbars.
> Actually, this is more a GTK shortcoming (that you can't just
> configure Athena behavior for all GTK apps), but if I at least have
> the option to override this at compile time of my most important
> application, it would be a good consolation.

You can at least use Emacs native scroll bars with GTK now (a minor bug 
prevented that previously).

	Jan D.

Re: GTK emacs (and access to GTK)

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> David Kastrup wrote:
>> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>> 
>>>I started to use GTK emacs a few months ago... Life was a bit busy so
>>>I forgot to say "the GTK port of Emacs is brilliant!"
>>>
>>>So I'm going to say it now:
>>>
>>>The GTK port of Emacs is brilliant.
>>>
>>>Well done to everybody involved in hacking it.
>> Well, I am missing an option to use Athena style scrollbars.
>> Actually, this is more a GTK shortcoming (that you can't just
>> configure Athena behavior for all GTK apps), but if I at least have
>> the option to override this at compile time of my most important
>> application, it would be a good consolation.
>
> You can at least use Emacs native scroll bars with GTK now (a minor
> bug prevented that previously).

Do you happen to know whether they have the three-button Athena
semantics (left/right buttons scroll up/down by equal amounts
proportional to click position, middle button "teleports")?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: GTK emacs (and access to GTK)

[Jan D.]

David Kastrup wrote:

>>You can at least use Emacs native scroll bars with GTK now (a minor
>>bug prevented that previously).
> 
> 
> Do you happen to know whether they have the three-button Athena
> semantics (left/right buttons scroll up/down by equal amounts
> proportional to click position, middle button "teleports")?

Yes they do, AFAIK the sematics are identical, they even use the same mouse 
pointer shapes.   I have not used native or Athena scroll bars much, but as for 
sematics, I can't tell the difference.

	Jan D.

Re: GTK emacs (and access to GTK)

[Jan D.]

Nic Ferrier wrote:
> I started to use GTK emacs a few months ago... Life was a bit busy so
> I forgot to say "the GTK port of Emacs is brilliant!"
> 
> So I'm going to say it now:
> 
> The GTK port of Emacs is brilliant.
> 
> Well done to everybody involved in hacking it.

Thank you.

> 
> 
> A related question: what are the views about allowing Emacs to create
> GTK objects directly? 
> 
> I know it is generally frowned upon to export native window system
> primitives into Emacs but because GTK is a GNU lib maybe there could
> be an exception. 
> 
> William Perry already wrote some code for XEmacs which could maybe
> serve as a guide?
> 
>   http://www.cs.indiana.edu/elisp/gui-xemacs/

I haven't looked at that code, so I can't say how much effort there is to do 
this.  It is something for the future, and has some advantages.  For example, 
Emacs could make its own file dialog where things like tramp works.

	Jan D.

Re: GTK emacs (and access to GTK)

[Nic Ferrier]

"Jan D." <jan.h.d@swipnet.se> writes:

> > A related question: what are the views about allowing Emacs to create
> > GTK objects directly? 
> > 
> > I know it is generally frowned upon to export native window system
> > primitives into Emacs but because GTK is a GNU lib maybe there could
> > be an exception. 
> > 
> > William Perry already wrote some code for XEmacs which could maybe
> > serve as a guide?
> > 
> >   http://www.cs.indiana.edu/elisp/gui-xemacs/
> 
> I haven't looked at that code, so I can't say how much effort there is to do 
> this.  It is something for the future, and has some advantages.  For example, 
> Emacs could make its own file dialog where things like tramp works.

I think it would improve usability for newbies because things like
configuration buffers could be made to appear (by preference) as GTK
dialogs.

As you say: things like tramp and even search and replace, could have
GTK facades.

Of course, no one here would use them. But I know a lot of programmers
who are just too scared to learn emacs, if they could fool themselves
into thinking it was just an editor they might take the plunge.

/8->

I'd be interested in helping hacking on this if someone else led the
effort.


Nic

Re: GTK emacs (and access to GTK)

[Peter Heslin]

On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
>  The GTK port of Emacs is brilliant.

Indeed it is.  One query: is the lack of support for the GTK
menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
by using the cursor keys) regarded as an outstanding bug to be fixed
for the next release, as a wish-list feature, or as a rejected and
undesirable feature?  I, for one, find that the support of XEmacs for
this feature is one of the few places where it has an advantage over
GNU Emacs.

It would be nice if it could be fixed for the next release, but it may
be a non-trivial task.  I once looked at the code, and saw that this
GTK feature was explicitly disabled by Emacs.  I tried enabling it,
and saw that there were weird side-effects in which point moved in the
buffer in addition to the menu navigation, and so I gave up
investigating it.

Peter

Re: GTK emacs (and access to GTK)

[Jan D.]

> On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
>>  The GTK port of Emacs is brilliant.
>
> Indeed it is.  One query: is the lack of support for the GTK
> menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
> by using the cursor keys) regarded as an outstanding bug to be fixed
> for the next release, as a wish-list feature, or as a rejected and
> undesirable feature?  I, for one, find that the support of XEmacs for
> this feature is one of the few places where it has an advantage over
> GNU Emacs.

The first, i.e. an outstanding bug to be fixed, but it is not critical 
for the next release.

>
> It would be nice if it could be fixed for the next release, but it may
> be a non-trivial task.  I once looked at the code, and saw that this
> GTK feature was explicitly disabled by Emacs.  I tried enabling it,
> and saw that there were weird side-effects in which point moved in the
> buffer in addition to the menu navigation, and so I gave up
> investigating it.

That sums up the work to be done quite nicely :-)

	Jan D.

Re: GTK emacs (and access to GTK)

[Nic Ferrier]

Peter Heslin <public@heslin.eclipse.co.uk> writes:

> On 2004-11-02, Nic Ferrier <nferrier@tapsellferrier.co.uk> wrote:
> >  The GTK port of Emacs is brilliant.
> 
> Indeed it is.  One query: is the lack of support for the GTK
> menu-accelerator keystrokes (eg. hitting F10 and navigating the menus
> by using the cursor keys) regarded as an outstanding bug to be fixed
> for the next release, as a wish-list feature, or as a rejected and
> undesirable feature?  I, for one, find that the support of XEmacs for
> this feature is one of the few places where it has an advantage over
> GNU Emacs.
> 
> It would be nice if it could be fixed for the next release, but it may
> be a non-trivial task.  I once looked at the code, and saw that this
> GTK feature was explicitly disabled by Emacs.  I tried enabling it,
> and saw that there were weird side-effects in which point moved in the
> buffer in addition to the menu navigation, and so I gave up
> investigating it.

I'm guessing that Emacs keymaps would get in the way.

So one would have to have a key binding that passed through the key
event to the GTK control.

This is the sort of thing that I'm talking about: tighter integration
with GTK as an option for Emacs. So by default Emacs (even Emacs/GTK)
would not have this stuff turned on but it would be available.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

As we are all aware, certain Emacs interactions are not as useful as
their shell like counterparts.

For example, using sql-mode to interact with PostgreSQL is not as
useful as doing it outside of Emacs.

The reason for this is that comint mode cannot effectively communicate
with certain programs to do things like completion.

I have a proposal for fixing that and this email describes it.

Most of the programs whose integration with Emacs we want to improve
use the GNU Readline library. This is why they have sophisticated
completion mechanisms.

GNU Readline works by defining an API for the things that a shell like
program will want to do and allowing keys to be bound to those API
functions.

So my suggestion for improving Emacs access to such programs is to add
an option to the GNU Readline library which allows Emacs to
call Readline API functions 'out of band'.

In effect this would work like this:

- Emacs starts a Readline program, eg: psql (the PostgreSQL client)
  with a special option specifying signifying this mode of operation.

- Readline somehow sees the option (maybe it is passed as an ENV var)
  and configures itself for this mode of operation

Readline and Emacs are now connected by some sort of stream (probably
just a standard comint/stdin scheme).

- Readline advertises to Emacs the functions the current program
  supports  by writing the information (a sexp?) to the stream

- Emacs reads the config from Readline and configures itself
  appropriately to bind Emacs keys to functions which send API calls
  to Readline over the stream.

- Readline communicates the status of the current line, and other
  status information (eg: completions) back over the stream for Emacs to
  display.


This seems like it wouldn't be that hard to add to Emacs and probably
not to Readline either.

Anyone have any thoughts?

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Stefan Monnier]

> - Emacs starts a Readline program, eg: psql (the PostgreSQL client)
>   with a special option specifying signifying this mode of operation.

A command-line argument is probably a bad idea (for cases like when you
start psql via a script (or a make file), ...).  An env-var would be good.

> This seems like it wouldn't be that hard to add to Emacs and probably
> not to Readline either.

Sounds like a good idea.

Such tools often offer things like a `listcompletions' commands which
Emacs can use to implement the completion itself.  Such a thing is used by
GUD for gdb.  Standardizing support for such things directly in comint might
also be a good idea, tho not as good because it only works for those
programs that go to the trouble of providing a `listcompletions' command.


        Stefan

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - Emacs starts a Readline program, eg: psql (the PostgreSQL client)
>>   with a special option specifying signifying this mode of operation.
>
> A command-line argument is probably a bad idea (for cases like when you
> start psql via a script (or a make file), ...).  An env-var would be good.
>
>> This seems like it wouldn't be that hard to add to Emacs and probably
>> not to Readline either.
>
> Sounds like a good idea.
>
> Such tools often offer things like a `listcompletions' commands which
> Emacs can use to implement the completion itself.  Such a thing is used by
> GUD for gdb.  

Readline has a few standard functions:

  int rl_complete_internal (int what_to_do)

  int rl_complete (int ignore, int invoking_key)

  int rl_possible_completions (int count, int invoking_key)

  int rl_insert_completions (int count, int invoking_key)

  int rl_completion_mode (rl_command_func_t *cfunc)

Which, AFAIK, is what *most* programs doing completion use.  This is
what Readline should advertise to Emacs (or whatever, this wouldn't be
Emacs specific necessarily).

There are a number of other Readline completion tools and, with
slightly a complex advertising protocol, it would be possible to hook
those in too.


> Standardizing support for such things directly in comint might
> also be a good idea, tho not as good because it only works for those
> programs that go to the trouble of providing a `listcompletions'
> command.

But it wouldn't be difficult for comint to detect when this behaviour
is offered by Readline, either:

- do a version detect on the readline .so

- have this feature make readline send a "hello", when the "hello"
  isn't received then comint will know this feature is not available.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    - Readline advertises to Emacs the functions the current program
      supports  by writing the information (a sexp?) to the stream

I am not quite sure what this means.  What questions would this
information answer?  Could you give an example?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

")
Message-ID: <87lldawrag.fsf@tapsellferrier.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Richard Stallman <rms@gnu.org> writes:

>     - Readline advertises to Emacs the functions the current program
>       supports  by writing the information (a sexp?) to the stream
>
> I am not quite sure what this means.  What questions would this
> information answer?  Could you give an example?

Sure.

Let's imagine I want to start psql (the PostgreSQL command line
client) in Emacs. This is what might happen, given my suggestion:

Emacs does:  READLINE_CTRL=API psql somedb

This opens the normal stream between the two programs, but puts
libreadline into 'api' mode


psql/Readline sends: (readline-api rl_insert_text 
                                   rl_delete_text
                                   rl_copy_text
                                   rl_kill_text
                                   rl_complete  
                                   rl_possible_completions
                                   rl_insert_completions)


This tells Emacs what function calls the readline program can accept.

The next step is that the user gives some input to emacs:

   select * from 

and then she presses C-TAB (the completion key). Emacs doesn't know
how to complete the line but it does know that psql/Readline supports
rl_complete so:

Emacs sends: (rl_complete "select * from ")

psql/Readline accepts the command, performs it and then:

psql/Readline sends: ("invoices" "orders" "expenses" "users")

and Emacs can display the completion list. The user types an "i" and
presses C-TAB so now....

Emacs sends: (rl_complete "select * from i")

and psql/Readline responds with: ("nvoices")

so now there is only one completion item Emacs can display the line:

    select * from invoices

At some point the user presses enter and Emacs passes the line to
psql/Readline again in some form that causes psql/Readline to execute
the line and send the output to the stream.



This would be a very cool way to solve the problem of getting at
completion services provided by, in particular, Readline enabled
programs.

It would require quite a lot of work to make Readline do it though.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    Let's imagine I want to start psql (the PostgreSQL command line
    client) in Emacs. This is what might happen, given my suggestion:

    Emacs does:  READLINE_CTRL=API psql somedb

    This opens the normal stream between the two programs, but puts
    libreadline into 'api' mode

It would be misleading to name this mode `api'.  Readline, being a
library, has an api.  That api is how the application communicates
with Readline.  It is always the same.

    psql/Readline sends: (readline-api rl_insert_text 
				       rl_delete_text
				       rl_copy_text
				       rl_kill_text
				       rl_complete  
				       rl_possible_completions
				       rl_insert_completions)


    This tells Emacs what function calls the readline program can accept.

Do you mean, commands to accept from Emacs?  If so, please don't call
them "function calls"; that is confusing.  Function calls into
Readline come from the app.

    Emacs sends: (rl_complete "select * from ")

    psql/Readline accepts the command, performs it and then:

That I can understand.  I think there needs to be some sort of quoting
convention, so that real user input can be distinguished from commands
to Readline itself.

I don't understand why there needs to be more than one command.  What
is it that Emacs needs to do other than use rl_complete?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

")
Message-ID: <873bzgbub2.fsf@tapsellferrier.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Richard Stallman <rms@gnu.org> writes:

>     Emacs sends: (rl_complete "select * from ")
>
>     psql/Readline accepts the command, performs it and then:
>
> That I can understand.  I think there needs to be some sort of quoting
> convention, so that real user input can be distinguished from commands
> to Readline itself.
>
> I don't understand why there needs to be more than one command.  What
> is it that Emacs needs to do other than use rl_complete?

What about history? Emacs' comint mode keeps quite a small history by
default and also doesn't save the history in a file, many Readline
programs do offer this.


If one used a quoting convention as you suggested then only one or two
commands would be necessary.

A quoting convention would be quite neat... but the trouble is it's
difficult to choose a quote.

So I was proposing a completly new way of communicating with
Readline. 

But maybe I should look again at a quoting convention.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kai Grossjohann]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> So I was proposing a completly new way of communicating with
> Readline. 

You mean, a way where readline doesn't read from stdin or from the
terminal?  Readline could open a Unix domain socket, I guess.

Kai

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Kai Grossjohann <kai@emptydomain.de> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> So I was proposing a completly new way of communicating with
>> Readline. 
>
> You mean, a way where readline doesn't read from stdin or from the
> terminal?  Readline could open a Unix domain socket, I guess.

The communication channel doesn't matter. It's what Readline does with
it that counts.

I was proposing having a new mode where Readline reads *commands* from a
stream, instead of keydata.

Right now what Readline does is this:

- read a character (or a keypress) from the input
- lookup the command the key is bound to
- execute the command

I was proposing an alternative communication system which would go
like this:

- read a command name and some arguments from the input
- execute the command

What rms is saying is that one could adapt the current Readline
communication channel to break out of the normal reading and switch
into the new mode. Maybe he's right. I'm not sure if it wouldn't be
more complicated to manage the state of the current line once commands
were being sent.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kai Grossjohann]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> What rms is saying is that one could adapt the current Readline
> communication channel to break out of the normal reading and switch
> into the new mode. Maybe he's right. I'm not sure if it wouldn't be
> more complicated to manage the state of the current line once commands
> were being sent.

For Emacs interaction, the normal mode might not be needed at all.
WDYT?

The command-oriented mode could provide a special command to accept
and process a line.

Kai

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Kai Grossjohann <kai@emptydomain.de> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> What rms is saying is that one could adapt the current Readline
>> communication channel to break out of the normal reading and switch
>> into the new mode. Maybe he's right. I'm not sure if it wouldn't be
>> more complicated to manage the state of the current line once commands
>> were being sent.
>
> For Emacs interaction, the normal mode might not be needed at all.
> WDYT?

That's right.


> The command-oriented mode could provide a special command to accept
> and process a line.

That's right. That was the idea.


But rms was suggesting that Readline already has all the functionality
for receiving lines (/8-) but a breakout might be useful to allow
Emacs to collect completions (and maybe history).

The trouble is how do you keep it all synchronized?


The user is entering a line in Emacs, with the text being sent to the
process so that Readline can see it in the normal way. So far she's
typed:

   select * from 

and now she presses C-TAB. Emacs has to ask Readline to do completion
of the current line and get the completions back. How does it do this?

Some quote thing could be sent, followed by a command. I guess what
Realine would have to do is:

- stop associating the input stream with the current line
- read the command
- execute the command
- respond with the output (delimitted in some way, maybe sexps?)
- go back to associating the input stream with the current line


So that might work.

But what quote to use?


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    What about history? Emacs' comint mode keeps quite a small history by
    default and also doesn't save the history in a file, many Readline
    programs do offer this.

If you are using comint, you have all the history in Emacs.
The history commands do not need to interact with the program.

    So I was proposing a completly new way of communicating with
    Readline. 

I thought these command would go thru the pty to the subprogram.
Are you thinking that Readline would talk to Emacs thru a socket?
That's ok if you make it work.

But you have not said what method of communication you have in mind.
Would you please say what it is?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     What about history? Emacs' comint mode keeps quite a small history by
>     default and also doesn't save the history in a file, many Readline
>     programs do offer this.
>
> If you are using comint, you have all the history in Emacs.
> The history commands do not need to interact with the program.

But comint's history is not as functional as the history provided by
some Readline programs:

- Readline programs often keep their history over invocations, comint
  does not

- Readline programs often have very large line historys, but comint
  tends to have a small line history (I guess this is changeable but
  it would be expensive for all comint buffers)

Also, Emacs does not 'add value' to line historys... so if they could
be delegated (if the sub program does have Readline and history
support then use it) it would be a good thing I think.


>     So I was proposing a completly new way of communicating with
>     Readline. 
>
> I thought these command would go thru the pty to the subprogram.
> Are you thinking that Readline would talk to Emacs thru a socket?
> That's ok if you make it work.

No. I think they would go through the pty to the subprogram. I was
suggesting that Readline would stop seeing the pty as a pty and treat
it more like a stream.

I am examining ways to achieve better integration with programs that
offer sophisticated command line facilities.

I may have a muck around with comint to see if I can get it to use
Readline expansions in a generic way.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Kim F. Storm]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

>> I thought these command would go thru the pty to the subprogram.
>> Are you thinking that Readline would talk to Emacs thru a socket?
>> That's ok if you make it work.
>
> No. I think they would go through the pty to the subprogram. I was
> suggesting that Readline would stop seeing the pty as a pty and treat
> it more like a stream.

That's a bad idea, imo.

Consider if the subprogram is a shell that can launch another program.
Then the readline extensions should only be used when the shell
has control, but not when other programs are running.

But how can you know when the shell is reading from the stream, or
when it is the sub-subprogram that's reading?


If you go to the trouble of improving this, it would be better to
have a control socket into readline which could ALSO inform comint
whether the readline API is currently active or not, i.e. it would
send messages like:

rl_ready
rl_hold
rl_continue
rl_exit

to inform you of whether it makes any sense to use any of the
rl_api functions.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: a suggested solution for better external' completion in certain emacs modes

[Stefan]

> But how can you know when the shell is reading from the stream, or
> when it is the sub-subprogram that's reading?

Yup, that's a very difficult problem.

> If you go to the trouble of improving this, it would be better to
> have a control socket into readline which could ALSO inform comint
> whether the readline API is currently active or not, i.e. it would
> send messages like:

A separate socket is very limiting since it only works for the
"original" program.  If you run a program from within your original program,
it won't work any more.  E.g. it won't work for a shell run via ssh on
a remote host; it won't work for a shell run via `su' or `sudo'; ...


        Stefan

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    > If you are using comint, you have all the history in Emacs.
    > The history commands do not need to interact with the program.

    But comint's history is not as functional as the history provided by
    some Readline programs:

That's too bad, but if you're in comint, you get comint's history
feature.  That is the only thing that makes sense.  However, we could
arrange for comint to save history from one invocation to the next, if
that is desired.

    No. I think they would go through the pty to the subprogram. I was
    suggesting that Readline would stop seeing the pty as a pty and treat
    it more like a stream.

What exactly would tell Readline to start treating the pty that way?
That is, how does Readline know it is time to read a completion
command rather than a line of input?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     No. I think they would go through the pty to the subprogram. I was
>     suggesting that Readline would stop seeing the pty as a pty and treat
>     it more like a stream.
>
> What exactly would tell Readline to start treating the pty that way?
> That is, how does Readline know it is time to read a completion
> command rather than a line of input?

An environment variable on the sub-program invocation.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    > What exactly would tell Readline to start treating the pty that way?
    > That is, how does Readline know it is time to read a completion
    > command rather than a line of input?

    An environment variable on the sub-program invocation.

The environment variable can't be changed during sub-program execution.
Are you saying that ALL communication with the subprogram will
use this new command protocol?  Not just when the user asks for
completion?

Re: a suggested solution for better external' completion in certain emacs modes

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

>     > What exactly would tell Readline to start treating the pty that way?
>     > That is, how does Readline know it is time to read a completion
>     > command rather than a line of input?
>
>     An environment variable on the sub-program invocation.
>
> The environment variable can't be changed during sub-program execution.
> Are you saying that ALL communication with the subprogram will
> use this new command protocol?  Not just when the user asks for
> completion?

Yes. It would be a completely new way for Emacs to communicate with
Readline programs. But it would still be implemented in comint so that
comint could pick when to use the new method and when to use ordinary
pty communication.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

    Yes. It would be a completely new way for Emacs to communicate with
    Readline programs. But it would still be implemented in comint so that
    comint could pick when to use the new method and when to use ordinary
    pty communication.

How would comint know when the process reading input is a
readline-using program?  Suppose I am talking to bash, which uses
readline.  Then I run ftp, which does not use readline.
If comint tries to keep using this new command protocol,
ftp would get totally confused.

There may be a way to resolve this problem.
However, what we want to do here now is make progress towards
a release, not discuss ideas for new features.  So I suggest
that those interested in trying to implement this sort of thing
should contact you, and you can discuss the idea outside this list
and see if you can make it work.

Re: a suggested solution for better external' completion in certain emacs modes

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> That's too bad, but if you're in comint, you get comint's history
> feature.  That is the only thing that makes sense.  However, we could
> arrange for comint to save history from one invocation to the next, if
> that is desired.

Right now it is up to the authors of comint-using modes to do that.
sql-mode for example does this at the end:

  ;; People wanting a different history file for each
  ;; buffer/process/client/whatever can change separator and file-name
  ;; on the sql-interactive-mode-hook.
  (setq comint-input-ring-separator sql-input-ring-separator
	comint-input-ring-file-name sql-input-ring-file-name)
  ;; Calling the hook before calling comint-read-input-ring allows users
  ;; to set comint-input-ring-file-name in sql-interactive-mode-hook.
  (comint-read-input-ring t)

And when the process is stopped:

  (comint-write-input-ring)

So the machinery is already in place.

I do agree that the history is far too small for today's standards.
comint-input-ring-size's value is 32 -- this is ok if all you can do
is move up and down the list, but these days we can list all matching
input, we can search backwards, etc.  32 makes no sense.  On my system
I set it to 500.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fifth law:
OOO  Never accept more work than you can handle in one night of hacking.

Re: a suggested solution for better external' completion in certain emacs modes

[Richard Stallman]

I will change the default for comint-input-ring-size to 150.

show-paren-mode stuffed in latest CVS

[Nic Ferrier]

I don't know much about show-paren-mode so I'm not sure I can spend
time trying to fix it.

But in the latest CVS build (today at 3pm GMT) it doesn't work
(there's just no highlight)


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Sam Steingold]

> * Nic Ferrier <asreevre@gncfryysreevre.pb.hx> [2004-11-08 15:14:06 +0000]:
>
> But in the latest CVS build (today at 3pm GMT) it doesn't work
> (there's just no highlight)
confirmed...
-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
A slave dreams not of Freedom, but of owning his own slaves.

Re: show-paren-mode stuffed in latest CVS

[Richard Stallman]

I fixed this a day ago--does it work now?

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

> I fixed this a day ago--does it work now?

Yes.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Kim F. Storm]

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I don't know much about show-paren-mode so I'm not sure I can spend
> time trying to fix it.
>
> But in the latest CVS build (today at 3pm GMT) it doesn't work
> (there's just no highlight)

Works here.

Did you try make bootstrap ?


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

storm@cua.dk (Kim F. Storm) writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> I don't know much about show-paren-mode so I'm not sure I can spend
>> time trying to fix it.
>>
>> But in the latest CVS build (today at 3pm GMT) it doesn't work
>> (there's just no highlight)
>
> Works here.
>
> Did you try make bootstrap ?

Yup.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Luc Teirlinck]

Nic Ferrier wrote:

   >> But in the latest CVS build (today at 3pm GMT) it doesn't work
   >> (there's just no highlight)
   >
   > Works here.
   >
   > Did you try make bootstrap ?

   Yup.

And you did this Monday or later?  (Kim fixed `make bootstrap' some
time Sunday.)

You mean that after:

emacs -q
M-x show-paren-mode
(abc)

you do not see the parentheses highlighted?

I do see the highlight.

Sincerely,

Luc.

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Nic Ferrier wrote:
>
>    >> But in the latest CVS build (today at 3pm GMT) it doesn't work
>    >> (there's just no highlight)
>    >
>    > Works here.
>    >
>    > Did you try make bootstrap ?
>
>    Yup.
>
> And you did this Monday or later?  (Kim fixed `make bootstrap' some
> time Sunday.)

I believe I gave a GMT reference on my original email. The timestamp
of the email will also tell you what day, but in short, yes: Monday.

I noticed that there were more changes checked in to the relevant
elisp file so I'm rebuilding again.

I'll let the list know what happens.



> You mean that after:
>
> emacs -q
> M-x show-paren-mode
> (abc)
>
> you do not see the parentheses highlighted?

Er, yes. That's what I mean.


-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Nic Ferrier]

It's working again now as of CVS at 9th Novemeber 2004 15:00 GMT

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk

Re: show-paren-mode stuffed in latest CVS

[Denis Bueno]

On 09 Nov 2004, at 11.30, Nic Ferrier wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
>> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
>>
>>> I don't know much about show-paren-mode so I'm not sure I can spend
>>> time trying to fix it.
>>>
>>> But in the latest CVS build (today at 3pm GMT) it doesn't work
>>> (there's just no highlight)
>>
>> Works here.
>>
>> Did you try make bootstrap ?
>
> Yup.

Broken here also, OS X 10.3.6. Did make maintainer-clean, ./configure 
--without-x --enable-carbon-app, make bootstrap.

--
Denis Bueno
PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index
"Politeness, n. The most acceptable hypocrisy." - Ambrose Bierce, The 
Devil's Dictionary

java and tag completion

[Nic Ferrier]

Can anyone tell me if tag completion works properly for Java source
files?

I've built a tags table in the correct way and I can find tags in the
source tree (which is useful) but what I really want is 'proper'
completion, ie: I type an instance variable "." half a method name and
Emacs works out what method I am using.

For example, in the following code:

  com.nic.Xyz x = new com.nic.Xyz("hello");
  x.foo

If I do tag completion now I would expect Emacs to complete the
code thusly:

  x.fooBar(

It doesn't. It does work sometimes...

Is it expected to work? Or is Java a bit too odd to do traditional tag
completion?


(I am sketching out an alternative using a similar system to tags).

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk