On Wednesday, 5 September 2018 at 17:34:17 UTC, ShadoLight wrote:
> On Wednesday, 5 September 2018 at 13:11:18 UTC, Jonathan M Davis wrote:
>
> It anyway appears that Vim/Emacs are often extended by plugins, and this will be the only way to have some project manage features.

I'm an Emacs user. I have never needed project management features. If I want to edit a new file, I do that.

You might be confusing "project management" with a build system. I'm not sure, but then I just use a build system such as CMake.

> I maintain that it is not practical trying to duplicate this in your editor of choice except if the amount of time you will save (from increased productivity) exceed the time taken to do this. I maintain that for bug fixing/support in a big organization this will hardly ever be the case.

True, but why would anyone want to duplicate it? The only reason I can think of is if the team is using Visual Studio and the .sln file is the agreed-upon build system. I know this happens in real life, but it shouldn't. And even then... open VS, add a file, go back to editing in Emacs/vim/whathaveyou. Or edit the XML directly.

> But even if you avoid this step and can build/run/test from the command-line it may not be optimal in certain debugging scenarios. See next point.

You don't have to build/run/test from the command-line, you can do it in-editor.

> Right, but depending on your type of debugging there is some things which just make more sense to do from right inside the debugger. If you hit a data value break-point or such on an attached debugger you can just double-click the line in the stack trace to go to the appropriate line in the IDE editor. No need to switch tasks to Vim/Emacs, do a go-to or whatever to get to the same place. The type of debugging I'm talking about is not your 'single step' variety.

No need to switch tasks to Emacs either, just run the debugger in Emacs and you can double-click if you want to. Although, if you're an Emacs user you're probably not going to want to use the mouse.

> I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left!

It's not a question of forgetting what IDEs can do. It's a question of either not needing those features or having them in the editor. I've used Visual Studio, Eclipse, IDEA, etc. I just don't like them.

This is what I need from an IDE: autocompletion, go to definition, on-the-fly syntax checking. I have all of that in Emacs.

> Again, it depends on what you mean by 'editing'.

I think he means... editing. Cutting, pasting, replacing, that kind of thing.

> If you are referring to coding where you are developing from scratch, then sure - I agree.

That's not editing, that's writing. In that case, notepad is enough, or cat. There's a reason why vim's normal mode is about editing, not writing (inserting).

> But the whole point of my post was to point out that this is not the only use-case for some of us. And in some of these other use-cases IDEs are actually superior to editors.

That's your opinion, you're entitled to it and I'm not going to try and change your mind. Mine is that no IDE gets close to the power of a good editor. In your favourite IDE, can you set up any key combination you want to:

1. Jump to the end of the current line
2. Check to see if there's a semicolon there
3. If not, add one
4. Open a new line beneath

No? I don't learn how to use Emacs, Emacs learns *me*.

And that was just a simple example.

> For another example IDEs are also in some ways a 'standard' inside big organizations in a way that any editor cannot be - the lowest barrier of entry to get new members up to speed in a team. And for some languages (Java/C#) you give up a lot by not developing inside an IDE. In fact, for Java and C#, the appeal/power of the languages is in many ways directly related to the IDE! Now throw in mixing C# with C++ (or even D) development... I'm sure you get my drift!

Most of what I'd need an IDE for in Java (I'd probably use IDEA if I were to write Java) I don't need for D.

On Wed, 12 Sep 2018 at 04:45, Atila Neves via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 5 September 2018 at 17:34:17 UTC, ShadoLight wrote:
> > On Wednesday, 5 September 2018 at 13:11:18 UTC, Jonathan M Davis wrote:
> >
> > It anyway appears that Vim/Emacs are often extended by plugins, and this will be the only way to have some project manage features.
>
> I'm an Emacs user. I have never needed project management features. If I want to edit a new file, I do that.
>
> You might be confusing "project management" with a build system. I'm not sure, but then I just use a build system such as CMake.
>
> > I maintain that it is not practical trying to duplicate this in your editor of choice except if the amount of time you will save (from increased productivity) exceed the time taken to do this. I maintain that for bug fixing/support in a big organization this will hardly ever be the case.
>
> True, but why would anyone want to duplicate it? The only reason I can think of is if the team is using Visual Studio and the .sln file is the agreed-upon build system. I know this happens in real life, but it shouldn't. And even then... open VS, add a file, go back to editing in Emacs/vim/whathaveyou. Or edit the XML directly.

Or use glob's in the XML.

On 8/22/2018 10:37 PM, Shachar Shemesh wrote:
> Let's start with this one:
> https://issues.dlang.org/show_bug.cgi?id=14246#c6

https://github.com/dlang/dmd/pull/8697

On 09/05/2018 01:05 PM, Ecstatic Coder wrote:
> 
> For instance, even for contract work, I use Geany for all my developments.
> 
> And a portable IDE like Geany is especially useful when developping *crossplatform* C++ multimedia applications which must be edited and tested both on Windows, MacOS and Linux.

Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine. :( Closest I've found since I moved to Linux is a custom-configured KDevelop, but it's still just not as good :( Heck, maybe I'll give Geany a go...

> Personally I use Geany even for Unity game development, as Unity allows to define which editor should be used to show the erroneous line of C# code when double clicking onto an error message.

I didn't know Unity could do that! I've just been manually going to the file/line of the error. I'll have to check into that! (Unity's relative unfriendliness to non-Unity-oriented workflows has always been one of my biggest pain points with it. Most normal IDEs aren't as problematic as Unity in those ways. Even the Unity's own team had to go to some significant lengths just to make automated builds possible, and even then, I'm not sure you can use just any off the shelf CI system. I really hate vertical integration.)

On 27/09/18 04:54, Nick Sabalausky (Abscissa) wrote:
> Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine.

Can you elaborate on what issues? Merely downloading and installing seem to work fine.

On 09/05/2018 01:34 PM, ShadoLight wrote:
> 
> I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left!

I sometimes wonder similar things about Vim/Emacs users, too ;)

But don't forget, not all non-IDE people are Vim/Emacs. And just like IDE development, plain-editor development didn't stagnate either. Many non-IDE users (like me) use editors that are far more contemporary than Vim/Emacs and *don't* have that learning curve.

And for that matter, sometimes I get the impression that IDE users think non-IDE editors are far less capable than they really are. For the most part, "IDE" mostly just means: editor + GUI-based buildsystem + debugger.


> If you are referring to coding where you are developing from scratch, then sure - I agree. You will be doing a lot of coding before building the 1st time. 

No offence, but if that's how someone's developing a new project, then they're doing things very, VERY wrong.

*Always* start a new project with some kind of "Hello world" or some such which builds and runs *right from the start*, and then grow it from there. I'm speaking from decades of experience doing things BOTH ways. Ultimately, any time you do a large amount of coding (writing and/or editing) in between working builds (no matter if it's the beginning or middle of development) then you're just asking for problems.

> For another example IDEs are also in some ways a 'standard' inside big organizations in a way that any editor cannot be - the lowest barrier of entry to get new members up to speed in a team. And for some languages (Java/C#) you give up a lot by not developing inside an IDE. In fact, for Java and C#, the appeal/power of the languages is in many ways directly related to the IDE!

I used to do a lot of Java and C#. I even used to be a big fan of C# back in the day (and I still don't really hate it or anything). But speaking from experience here: It's not so much that the IDEs are a great feature of those languages, it's more like (especially with Java) the IDEs are used as a crutch to help mitigate major faults in the languages.

But that said, there are examples of IDEs that really do provide a genuine benefit beyond mitigating language problems. These tend to be domain-specific to at least some extent. Some examples that come to mind are the old "RAD"-style tools for GUI apps (like Delphi and VB6). Or Unity3D for either games or Flash-like multimedia.

On 09/26/2018 10:33 PM, Shachar Shemesh wrote:
> On 27/09/18 04:54, Nick Sabalausky (Abscissa) wrote:
>> Man, I wish SOO much, that was true of my favorite editor (Programmer's Notepad 2). I love it, but it's a windows thing and has some issues under wine.
> 
> Can you elaborate on what issues? Merely downloading and installing seem to work fine.

The main big one was that the option to use MRU order for Ctrl-Tab file-switching doesn't work. Instead, it ends up being some kind of semi-random order.

I know that doesn't sound like a big deal, but it turned out to be a HUGE drain on both my mental focus and my productivity. (I habitually rely *very* heavily on Ctrl-Tabbing between two main documents I'm focusing on - or occasionally three. And the MRU behavior is very deeply ingrained in my muscle memory. Technically, I could save-and-close all other documents, but that also messes with my workflow and mental processes.) I love the program so much that I tried to work through it (and filed bug reports, etc), but ultimately it proved to be too much of a problem.

Another, smaller, issue was that it doesn't start up nearly as fast under wine (still WAY faster than most IDEs though.) Although that's admittedly very minor, and not a deal-breaker. Although it's near-instant startup was one of the things I loved about it back on windows.

I seem the remember there being one other quirk I ran into (maybe related to find or replace?), but it's been awhile so I don't remember exactly what that was.

On 09/26/2018 08:23 PM, Nick Sabalausky (Abscissa) wrote:
> On 09/05/2018 01:34 PM, ShadoLight wrote:
>>
>> I sometimes wonder if the Vim/Emacs 'affectionados' spend so much time mastering their editors (which by all accounts have a steep learning curve), that they forgot that IDE development did not stagnate after they left!
> 
> I sometimes wonder similar things about Vim/Emacs users, too ;)

A lot of people use Vim/Emacs plus a full IDE.

I use IntelliJ for work. I also use Vim. Vim is much better when I know my APIs, and it's exceptional at applying transformations to a block of text. IntelliJ is much better when I'm using an API I'm unfamiliar with. Sometimes I'll switch back and forth editing the same file -- I'll hack something together in Vim and then use IntelliJ to quickly find and fix errors.

For D, unfortunately, I haven't gotten an IDE to work yet. Not with any appreciable degree of autocomplete. So I stick with Vim pretty much entirely.

> But don't forget, not all non-IDE people are Vim/Emacs. And just like IDE development, plain-editor development didn't stagnate either. Many non-IDE users (like me) use editors that are far more contemporary than Vim/Emacs and *don't* have that learning curve.

Pretty much all advanced features in a text editor have a learning curve. Kind of unavoidable; we're asking text editors to do complex things. GUI editors can offer *less* of a learning curve, and they can offer advice better, but they can't eliminate it entirely.

> And for that matter, sometimes I get the impression that IDE users think non-IDE editors are far less capable than they really are. For the most part, "IDE" mostly just means: editor + GUI-based buildsystem + debugger.

Autocomplete, highlighting errors, semantic code navigation, and displaying extra semantic information are other IDE features that text editors tend to lack.

On the other hand, I've seen projects billing themselves as IDEs when they were pretty much just a tree view for files in the project, a GtkSourceView, and a build button.