[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IDE
From: |
raman |
Subject: |
Re: IDE |
Date: |
Sat, 10 Oct 2015 16:26:17 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
"John Wiegley" <address@hidden> writes:
Well said. Let's focus on functionality -- and the rest -- including a
multiplicity of visual look-and-feel setups will follow along with
everything else.>>>>>> martin rudalics <address@hidden> writes:
>
>> I never use side windows so I can't tell whether they still work. I have
>> written a frame-tabs.el package based on side windows but I don't use that
>> either. At the time I installed the side windows functions I also added a
>> texinfo section but Stefan later asked me to remove it. That info does not
>> reflect later changes to the code so it might be outdated. You have to live
>> with the doc-strings which should be fairly accurate.
>
> We should define what we want from a "more IDE" Emacs. For example, I do not
> want window-layout functionality. That's a presentation aspect of IDEs that's
> entirely separate from what I want from them.
>
> Right now we have a pretty nice infrastructure for things like indenting code.
> That is, there are standard keybindings (TAB, C-M-\), a standard per-buffer
> override variable (indent-line-function), a standard command
> (indent-according-to-mode), and ways for packages like Yasnippet to override
> the meaning of TAB without ruining functionality.
>
> I think that what an "IDE is" has little to do with what it looks like. Emacs
> being a better IDE, to me, means making IDE-like functionality a first-class
> citizen, as we do with indenting. This would provide a core for fancy display
> modules to build on top of.
>
> I also don't think core Emacs should *provide* this functionality, since
> that's impossible, given how many different languages and use cases there are.
> It's more about giving developers a common API to base their work on, so that
> we maximize collaboration between them.
>
> Here is a list of functionality I think should be first-class, structurally
> speaking (that is, an API will exist, but it may not do anything until a
> contributor implements the functionality for their language). The ones with
> a * mean areas where we're already succeeding to some degree:
>
> * indentation (see above)
> reformatting
> * syntax highlighting (font-lock)
> help at point
> documentation lookup (sadly, fewer projects use Info these days)
> ? completion
> refactoring
> semantic editing (for example, paredit)
> * compilation (M-x compile)
> live compilation (flymake/flycheck)
> * REPL (comint)
> running tests
> * debugging (GUD)
> * version control (VC)
> profiling
> code coverage
> app interaction
>
> The reason I don't have a * next to completion, despite having so many things
> capable of doing it (company, auto-complete, ido, hippie-expand, helm, ivy,
> etc., etc.), is that there are too MANY ways to do it. This is where I think
> proper IDE support could help.
>
> If we have a single paradigm for "determining interesting details about the
> buffer, and near point", with the ability to refine the query based on what is
> need, optionally cache results, etc., then the competing libraries we have
> today could share functionality. The present day `all-completions` function is
> too spare to fit this bill, so it's less of an IDE feature in my book and more
> just a Lisp library function. For example, I've written nearly the same
> backend code for at least 4 different completion/lookup packages, and each
> time I wonder how we could do better here. The differences are so minimal.
>
> To reiterate: I think Emacs becomes more of an IDE when it provides the
> backbone of an IDE, and not when it looks like one. We have some pieces of
> that backbone already, which have avoided fragmentation in those areas, but we
> need more. A standardized way to do tooltips, popups, visual completion
> selection (or at least the structure), REPLs that interact with buffer
> contents, etc., would give us a foundation to move to the next step.
>
> John
>
--
- Re: IDE, (continued)
- Re: IDE, Dmitry Gutov, 2015/10/10
- Re: IDE, Daniel Colascione, 2015/10/10
- Re: IDE, Andreas Röhler, 2015/10/11
- Re: IDE, Steinar Bang, 2015/10/12
- Re: IDE, Eli Zaretskii, 2015/10/12
- Re: IDE, David Kastrup, 2015/10/12
- Re: IDE, Richard Stallman, 2015/10/13
- Re: IDE, Steinar Bang, 2015/10/14
- Re: IDE,
raman <=
- Re: IDE, Eric Ludlam, 2015/10/10
- Re: IDE, John Wiegley, 2015/10/10
- Re: IDE, Eric Ludlam, 2015/10/12
- Re: IDE, John Wiegley, 2015/10/12
- Re: IDE, Richard Stallman, 2015/10/11
- Re: IDE, Przemysław Wojnowski, 2015/10/15
- Re: IDE, Jean-Christophe Helary, 2015/10/11
- Re: IDE, Przemysław Wojnowski, 2015/10/11
- Re: IDE, Jean-Christophe Helary, 2015/10/11
- Re: IDE, Przemysław Wojnowski, 2015/10/15