LINUX.ORG.RU

Столлман дал добро на интеграцию Language Server Protocol в GNU Emacs

 , , ,


0

4
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I am urging the GCC developers to work on implementing the language
  > > server.

  > I would then suggest that Language Server Protocol support be
  > integrated into Emacs (as opposed to being available in ELPA or what
  > have you).

I will tell this list if I convince them.
So far, they are unconvinced.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Подробности:

https://lists.gnu.org/archive/html/emacs-devel/2017-04/msg00798.html

★★★

Последнее исправление: Oxdeadbeef (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

потому. иди лучше клятву почитай ))

mos ★★☆☆☆
()

А что с ECB в Emacs 25 и выше?

DR_SL ★★★★★
()
Ответ на: комментарий от zz

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

I-Love-Microsoft ★★★★★
()

Ну правильно, мне хипстеры все уши прожужжали какая в VS.Code хорошая штука этот LSP. Вот теперь в emacs завезут, можно будет поглядеть

Deleted
()
Ответ на: комментарий от I-Love-Microsoft

Столлман-то как раз может быть под колпаком АНБ, т.к. зачастую критикует правительство и т.д. Так что для него это нормально.

Bad_ptr ★★★★★
()

Лучше бы редактор текстов добавили ...

anonymous
()
Ответ на: Круть! от Camel

хорошая поддержка Java?

Очень хотелось бы, а то на идее слишком медленно все ворочается и не удобно.

Oxdeadbeef ★★★
() автор топика

Штульман разве что-то решает вообще в разработке емакса? Я думал он давно уже не у дел.

x4DA ★★★★★
()
Ответ на: комментарий от makoven

Горюешь что не GraphQL?

Те же яйца. Разбирать-то как? Ладно, в общем-целом JSON даже проще чем SLL(1) и может разбираться т.н. visibly pushdown automata (самый обычный МП-автомат, только таблица переходов попроще т.к. есть «магические» символы «{}[]:,»). Но, какого хрена?

Парсеров — я имею в виду *нормальных* парсеров — для языков без сборки мусора раз-два и нет. Модель документа без весьма нетривиального storage manager задрочит систему вызовами malloc/free. Собственно, поэтому JSON просто использовать во всяких скриптовых языках, «под капотом» сидит storage manager, да и жестких требований по памяти и производительности не предъявляется.

И самое главное, всё уже давным-давно решено: TLV. Даже наивная реализация будет эффективнее. Причём каждый более-менее приличный вендор (а некоторые и по два раза) уже наваяли какую-нибудь реализацию TLV, не считая ASN.1. Нет, сцуко! Мы будем форсить хипстерочитаемые (поскольку TLV — человекочитаемый формат, особенно если он разрабатывался по гумантистическим принципам см. напр. BitTorrent) форматы!

Macil ★★★★★
()
Ответ на: комментарий от Macil

Парсеров — я имею в виду *нормальных* парсеров — для языков без сборки мусора раз-два и нет

Для плагина текстового редактора нормальный парсер и не нужен. Это ж не хайлоад)

TLV

Поддерживаю. Хотя бы JSON в netstrings оборачивали, чтоб не искать сбалансированную закрывающую скобку для каждого сообщения. Или JSON-RPC 2 требует чтобы сообщение было в одну строку? Не нашел в спеках, хоть примеры все и однострочные

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 2)
Ответ на: комментарий от makoven

Или JSON-RPC 2 требует чтобы сообщение было в одну строку?

Нет. Не требует. Да и проявляется в чистых TCP-серверах. Для хипстожсонрпц с вызовом одного метода на запрос с заголовком Content-Length это неактуально.

Это ж не хайлоад)

Это смотря кому, где, и при каких обстоятельствах. Куда девать высокую латентность такой «архитектуры»?

Macil ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.