[emacs] Что дальше?

>Но пока не догнал фишку - чем она удобнее чем, например, qtcreator?

Ты ещё не постиг дзен, юный падаван. Начнёшь писать на Common Lisp - поймёшь.

А что, в QtCreator тоже для LaTeX писали? И как, удобнее, чем в auctex?

А что, в QtCreator тоже для LaTeX писали? И как, удобнее, чем в auctex?

Выразился немного сумбурно. В QtCreator писал на c++, а emacs использую latex.

>В QtCreator писал на c++

Дали мне как-то потыкать плюсато-кутешный проект в QtCreator. Через 15 минут начало жечь пальцы, пришлось скорее бежать к своей машине, к живительному Emacs, и пообщаться с психотерапевтом.

Там уже Cedet допилили до нормального состояния, чтобы не хуже чем в QtCreator индексировал исходники и выдавал подсказки? И с интеграцией GDB были улучшения (хотя бы показ Qt/STL типов)?

Не знаю. Особой нужды в них не испытываю, потому и не пользуюсь. Сразу скажу - в проекте, над которым я работаю, примерно 1.7 млн sloc.

>использую его для latex.

Что дальше?

AUCTex

Мне бы для плюсов удобство. С латехом я разобрался.

cedet либо xrefactory

А как работаете с большим проектом? Find+grep вместо нормального семантического поиска? И отладчик вообще не используется?

> хотя бы показ Qt/STL типов

пилим

> во всех прогах

И ты ещё спрашиваешь, что делать дальше.

Сам более менее помню, где что лежит. Пару-тройку раз точечно грепаю :) Отладчиком в силу специфики работы пользуюсь студийным, но это бывает один-два раза в месяц.

cedet + gnu global... показ qt/stl структур никак не зависит от емакса, а исключительно от самого gdb - погугльте макросы для gdb, он тогда и в консоли будет показывать структуры

Двадцать лет все писал исключительно в emacs. Но потом вышла visual studio 2010, и emacs мне теперь нужен только для latex-а.

Мир изменился, то, что было правдой еще пару лет назад сегодня уже устаревшая чушь. Так что забудьте вы все про emacs, кончился он.

Не верю. После двадцати лет в Емаксе бросить его - не верю. Проще бросить курить, бухать и колоться одновременно.

> Не верю. После двадцати лет в Емаксе бросить его - не верю. Проще бросить курить, бухать и колоться одновременно.

Не, ну у меня в MSVS кнопочки все настроены как в емаксе, от таких привычек отказываться нереально.

Что меня купило - это семантические возможности редактора. Аналогично кстати и в Eclipse. Время Emacs ушло - поддержку языкам делать на уровне регэкспов и тормозного недопарсера в semantic, способного понимать только top level expressions можно было в 199x, но никак не в 201x. И инфраструктура emacs уже настолько устарела, что в нее это и не впихнуть. Он исчерпал ресурс. Он был прекрасен, но он умер.

Да и фрустрация от dynamic scope накопилась. Elisp раздражал. Теперь у меня есть F#, на котором и пишу расширения к VS. И, да, изкоробочный редактор для F# рвет замечательную tuareg-mode как Бобик тапки.

Интересно то, что для semantic можно написать полноценный парсер, который понимает не только top level, но и имеет полное дерево разбора. Только вот(наверное) из-за скорости elisp этого никто не делает. В листе расслыки именно эту причину и указывали, а так вобще-то это обычный генератор LALR(1) парсеров, на котором можно выразить довольно много(в частности что бы информации хватило для семантических подсказок).

для semantic => на semantic

Именно так. Он тормозит, и на lalr(1) слишком мало языков можно выразить.

Во первых - не для всех потребностей надо строить полноценное дерево разбора, это же не компилятор.

Во вторых - приведите пример языков(кроме C++) для которых сложно построить lalr(1) парсер. Haskell например парсится(не для компилятора конечно, потому что надо учитывать приоритет введенных пользователем операторов), конечно есть некоторые конфликты, но они обычно решаются обычными средствами. И для автокомплита и навигации по коду не нужно совершенно правильное дерево

1. Умеет ли он делать поиск по всему проекту?

2. А можно как в QtCreator максимализировать рабочее пространство.

3. ede+cmake или только с make?

>2. А можно как в QtCreator максимализировать рабочее пространство.

C-x 5 2

Не разворачивает.

Прежде чем переходить куда-то стоит понять что ты хочешь. Надо сесть и написать workflow твои и понять как ими пользоваться.

A emacs позволяет сделать это не отходя от кассы;).

ну собственно к его услугам я и обратился =)

> Во первых - не для всех потребностей надо строить полноценное дерево разбора, это же не компилятор.

Мало дерево строить, надо еще и вывод типов на нем делать, и много чего еще. Это не компилятор, это больше чем компилятор.

Во вторых - приведите пример языков(кроме C++) для которых сложно построить lalr(1) парсер.

Как будто C++ мало. Самый популярный язык - и его уже нельзя нормально поддерживать в IDE.

А ведь есть еще всякие там Python-ы и прочая прелесть. Есть C# с LINQ-ом. Есть javascript с его синтаксисом регэкспов.

Ну и главное - LALR(1) не умеет как следует умирать. Не умеет прощать ошибки. Для IDE это непростительно.

> И для автокомплита и навигации по коду не нужно совершенно правильное дерево

PS: этого мало. MSVS умеет намного больше.

> И для автокомплита и навигации по коду не нужно совершенно правильное дерево

Как это не нужно? Необходимо полностью знать тип выражения в точке автокомплита, иначе фигня будет, а не семантически корректный автокомплит. Для навигации аналогично нужно ресолвить все символы в коде. Как это предлагается делать без построения корректного AST и учета семантики языка?

Можно нормальное описание того что делает MSVS для автокомплита и анализа кода?

Для навигации по коду, надо знать : (имя символа, тип символа, позицию символа), а в языках типа C++ все типы переменных описываются явно, из чего следует что делать полный парсинг не так уж и не обходимо. Конечно надо делать парсинг выражения возле точки комплита для получения информации, но все же это далеко не полный парсинг файла.

А для питона вобще статический анализ затруднен, думаю вы понимаете почему.

Для навигации по коду, надо знать : (имя символа, тип символа, позицию символа), а в языках типа C++ все типы переменных описываются явно, из чего следует что делать полный парсинг не так уж и не обходимо.

Откуда можно узнать "(имя символа, тип символа, позицию символа)", если не делать полный разбор кода?

Пример:

void T(int) {}
int x;

class A {
  int f() {
    T(x);   // declaration of variable x
  }
  // a lot more lines of code go here...
  typedef int T;
};

Как предлагается сделать корректный переход к определению T внутри A::f, если даже разбора всего кода выше не хватает, чтобы корретно учесть контекст?

Под полным разбором кода я понимаю не полный анализ файла, а построение полного синтаксического дерева, что в данном случае в принципе не требуется. Достаточно просканировать определения, и учесть область видимости, хотя конечно для этого прийдется проанализировать весь файл(а определения это меньшая часть грамматики С).

Кстати обычно наибольшие затруднения вызывает препроцессор, а не разбор.

> Достаточно просканировать определения, и учесть область видимости

И так на каждый чих постоянно сканировать все подряд? А для контекста еще и AST строить (без него ничего вывести не удастся)?

И как в итоге должен работать поиск references, для которого всегда нужно учитывать контекст?

Кстати обычно наибольшие затруднения вызывает препроцессор, а не разбор.

Если разбирать только одну конфигурацию проекта (как компилятор видит единицу трансляции при сборке), то препроцессор вообще не помеха. Сложно обрабатывать сразу все конфигурации, т.к. нужно парсить единицы трансляции по несколько раз с разными настройками для препроцессора.

kamre, Вы ещё такой пример приведите:

struct Object
{
    int i;
};

template <class T>
int foo(T *p)
{
    p->[ГДЕ АВТОКОМПЛИТ??? ГДЕ Я СПРАШИВАЮ??? ЭТО ЖЕ ОЧЕВИДНО ЧТО p УКАЗЫВАЕТ НА Object!!!!1!11!]
}

:)

Кстати, нормальная IDE должна знать про все инстанцирования шаблона в проекте. Поэтому и для параметров шаблона должен работать автокомплит.

> Кстати, нормальная IDE должна знать про все инстанцирования шаблона в проекте. Поэтому и для параметров шаблона должен работать автокомплит.

:)))) жжёшь :)

Мое мнение : анализ кода нужен только для навигации по проекту, что бы можно было быстро разбораться в чужом коде.

Фичами типа автокомплита практически не пользуюсь.

Для меня автокомплит тоже не вещь первой необходимости, можно обходиться словарным вроде M-/ в Emacs. Но для навигации и поиска references (для разбирания чужого кода очень полезная вещь) необходимо полностью разрешать контекст для всех символов, а значит строить AST и делать семантический анализ. Для C++ лучше всех это умеет делать Xrefactory, правда тормоз он еще тот.