[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: {Spam?} Re: progmodes/project.el and search paths

From: Eric Ludlam
Subject: Re: {Spam?} Re: progmodes/project.el and search paths
Date: Thu, 06 Aug 2015 07:27:34 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

On 08/05/2015 09:42 AM, Stefan Monnier wrote:
It's a very limited view of a project, so other packages who want to
work on a project cannot depend on much information unless they ask one
backend directly.
Yes, it's very limited, simply because there hasn't be any other such
"other package" which required something else.  As mentioned I can see
things like "flymake" imposing extra requirements (mostly a new method
to compile some file(s) and return the corresponding compilation

I would think that backend projects can also depend on services from a generic project system. Comint provides a generic way to interact with a shell command. Using comint is easier than starting from scratch and makes no assumptions by providing for a wide range of features that might be needed by sub shells. A side effect is that every subordinate shell buffer in Emacs is consistent, configuring options in comint works everywhere, and keybindings are the same. Another side effect is that a you can write services that work with comint that thus work in many different shells. Wouldn't it be cool if users could write things that feel like project management backend features that work with multiple back-ends.

It would be nice if the generic base project were the same. Any project backend you use would have similar keybindings, menus, detection mechanisms, file location systems, etc because it will be easier to use the base support than invent something new.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]