Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs 26.1 released

lists.gnu.org

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Emacs 26.1 released

#91

Post by mr_overalls »

TeMPOraL wrote: post #44
reitanqild wrote: post #37

Earlier quoted context omitted.

Also: not for everyone. I keep hearing people mentioning vim and emacs but I have a strong suspicion that if people spent the same time that they now spend learning and customizing vim and emacs learning a more modern IDE or advanced editor they'd be even more effective (except when they need to edit over ssh). Personally I use Visual Studio Code all day now. But I've also been happy with Netbeans, IntelliJ, eclipse…

> if people spent the same time that they now spend learning and customizing vim and emacs learning a more modern IDE or advanced editor they'd be even more effective (except when they need to edit over ssh) Or except if they need to blog. Or manage repositories. Or manage tasks. Or read e-mail. Or... The thing with Emacs is that it offers you an universal, consistent interface for everything text. That includes code…

> The thing with Emacs is that it offers you an universal, consistent interface for everything text.

This. As my programming career extended past its first decade, I began (like many people) to feel the fatigue of constantly adapting to new editors, email readers, file managers, etc. The long-term _consistency_ of Emacs gives me an anchoring point and frees me to pay attention to deeper patterns - data structures, architectures, concepts - things that matter more than the tooling du jour.

Re: Emacs 26.1 released

#92

Post by kinleyd »

gkya wrote: post #11

I suggest to anyone serious w/ Emacs to follow the master branch. I have been compiling once a week since almost a year and did not experience any breakage. My routine is fetch, see the output from "git diff HEAD..FETCH_HEAD -- etc/NEWS | less", pull --ff, compile and install. The benefit being you don't get a whole bunch of news when you update to a major version, but get there gradually; and also the master has the…

On the strength of your recommendation, and an unwillingness to wait for the arch repos to update emacs, I went ahead and installed the master branch. So I'm now on version ... 27.0.50. Skipped 26.1. :)

As you said, the change was smooth and I got to enjoying all the new fixes and stuff. But my word, it was over a gigabyte of downloading, which I didn't expect! Still, worth it.

Re: Emacs 26.1 released

#93

Post by bmn__ »

henry_flower wrote: post #87
bmn__ wrote: post #86

Earlier quoted context omitted.

> not for everyone I feel that acutely. Emacs is shit because despite its age, it does not even meet some sane minimum requirements for text editors. No localisation. No tabs. Window cannot be maximised prior to setting some obscure option. Menu items and buttons do not have underlined letters (i.e. accelerators). The vast majority of the options cannot be accessed through the menu or dialogues, instead you get a non…

> Emacs is shit pls don't say that :( there's exactly 0 ppl in the world who get paid for writing emacs. nobody is selling the editor as snake oil liniment that ought to remove all the grievances. > No localisation what do you mean? I can read/type in emacs in all 3 human lang I know/use daily. > No tabs true although `M-x speedbar` can display the list of all open buffers in a vertical fashion > Window cannot be max…

Are you involved with emacs development or just a user?

> there's exactly 0 ppl in the world who get paid for writing emacs

I, too, am a free software author in my spare time and not paid for it. Not being paid for a labour of love does not make one exempt from criticism.

>> No localisation

> what do you mean?

The software's user interface and on-line documentation should be implemented in my language, but it's available only in English.

> M-x speedbar

That displays a hierarchical file browser in a separate window, not a list of documents.

>> Configuration is stored as code

> that's the whole point

Occasionally the sheer power is useful because a programming language gives you the power to do things that are not possible or very hard otherwise.

But for the vast majority of cases, most of the time, configuration should be stored in the moral equivalent of an INI file. That way I can process it externally. As it is now, I need to code a parser for elisp and replicate a decent chunk of the emacs runtime environment. That's just too difficult and time-consuming for anyone.

Very much related: http://www.cs.dartmouth.edu/~sergey/langsec/occupy/

Turing-completeness should be the exception, not the norm, and only used when actually needed, not for trivial cases.

> long lines […] emacs suddenly becomes dog slow

Many editors have that same problem, so that one doesn't bother me much.

Re: Emacs 26.1 released

#94

Post by rekado »

AlexeyBrin wrote: post #56
rekado wrote: post #29

Earlier quoted context omitted.

It is not an idea that is supported by the whole Emacs community. It is an idea that is supported by the Guile community and RMS. Work has been done to make Guile Emacs work, but it is still slow (as it doesn't seem to compile elisp before running it) and somewhat experimental. It really just needs someone to make it work more reliably and then demonstrate that it is a desirable thing not just in theory but in practi…

> It is not an idea that is supported by the whole Emacs community. One problem is portability, Emacs Guile means alienating Windows users. Guile does not run on Windows. As it is now, I can use same Emacs on my home Mac system, on my work Windows 10 computer and on various Linux servers.

> Guile does not run on Windows

This hasn't always been this way, though, as far as I know. It is also not an insurmountable obstacle, but it is one of many small things that make Emacs developers worry.

Another problem that makes Guile Emacs somewhat less attractive is the difference in string handling. Emacs deals well with improperly encoded strings (because that's what people throw at it), whereas Guile prefers to either deal with byte streams or properly encoded strings. Shuffling strings back and forth between an Elisp and a native Guile representation is not very attractive.

Re: Emacs 26.1 released

#95

Post by henry_flower »

bmn__ wrote: post #93
henry_flower wrote: post #87

Earlier quoted context omitted.

> Emacs is shit pls don't say that :( there's exactly 0 ppl in the world who get paid for writing emacs. nobody is selling the editor as snake oil liniment that ought to remove all the grievances. > No localisation what do you mean? I can read/type in emacs in all 3 human lang I know/use daily. > No tabs true although `M-x speedbar` can display the list of all open buffers in a vertical fashion > Window cannot be max…

Are you involved with emacs development or just a user? > there's exactly 0 ppl in the world who get paid for writing emacs I, too, am a free software author in my spare time and not paid for it. Not being paid for a labour of love does not make one exempt from criticism. >> No localisation > what do you mean? The software's user interface and on-line documentation should be implemented in my language, but it's avail…

just a user; wrote several elisp pkgs

> Not being paid for a labour of love does not make one exempt from criticism.

I'm fine w/ criticism; I'm just of an opinion that the word "shit" is a bit too much; also I'm fascinated how the current emacs maintainer handles such a complex proj

> The software's user interface

which part? the majority of the user-visible 'interface' consists of so called interactive elisp cmds (runnable via M-x ...); the help for such cmds (or the whole modes) gets extracted from the corresponding fn comments & gets updated in real time when/if the code changes.

> and on-line documentation should be implemented in my language, but it's available only in English.

this is tough. the user's manual is huge. it'd probably take a year for a pro translator to produce a meaningful result

the elisp manual is even bigger

the tutorial is available in multiple lang, though

>> M-x speedbar That displays a hierarchical file browser in a separate window, not a list of documents.

click w/ the rigth btn in the speedbar win: a popup menu will appear. select speedbar->displays->buffers

Re: Emacs 26.1 released

#97

Post by phillord »

krylon wrote: post #30

Completely OT, but I remember when building Emacs was like "there goes my afternoon". On my current desktop (which is kind of snazzy, I admit), it takes less than 30 seconds wall clock time. This is one aspect of The Future(tm) I definitely appreciate. ;-)

Build from the source tarball, or a bootstrap build? For me, I can't get the later much below 10 minutes and often much longer.

Re: Emacs 26.1 released

#98

Post by jasomill »

na85 wrote: post #14
gkya wrote: post #11

I suggest to anyone serious w/ Emacs to follow the master branch. I have been compiling once a week since almost a year and did not experience any breakage. My routine is fetch, see the output from "git diff HEAD..FETCH_HEAD -- etc/NEWS | less", pull --ff, compile and install. The benefit being you don't get a whole bunch of news when you update to a major version, but get there gradually; and also the master has the…

I similarly encourage any Mac users who are serious about emacs to use Mitsuharu Yamamoto's fork, which adds several usability improvements that RMS refuses to endorse and is just generally a better experience on Mac. Mainline GNU Emacs feels clunky and obsolete by comparison.

Also, if you're worried about the occasional regression, you can archive an installer package of the OS X .app (--with-ns) version each time you build by adding something along the lines of

    version="$(date +%Y.%m.%d.%H.%M.%S)"
    packagedir="$HOME/Unreliable/Packages"

    pkgbuild \
      --identifier at.jasomill.pkg.org.gnu.Emacs \
      --version "$version" \
      --install-location /Applications \
      --component nextstep/Emacs.app \
      "$packagedir/Emacs-$version.pkg"
to your build script; add

    sudo installer -package "$packagedir/Emacs-$version.pkg" -target /
if you also want to install. The resulting package is also a handy way to push the updated version to multiple Macs.

Note, however, that I've reverted to a previous version maybe twice in the past 5+ years of weekly builds (from the GNU master branch), and even in these cases, the regression didn't affect core editing functionality (last one I remember, editing over ssh via tramp was failing in certain circumstances [that I never got around to working out in detail]).

Re: Emacs 26.1 released

#99

Post by jasomill »

jordigh wrote: post #85
skissane wrote: post #72

Earlier quoted context omitted.

Couldn't one way out of the impasse be to enhance GNUstep to implement the macOS APIs/features which Yamamoto's fork uses? RMS doesn't want to add features only supported on proprietary platforms, but so long as one free software platform supports the same feature, that should answer RMS' objection.

Yes, this is more or less what rms wants to happen: that GNU gets the benefits of macOS. Then when both OSes can use those colourful emojis, he will accept the code into Emacs.

One of the examples RMS gave where this happened (in GCC) relates directly to OS X history, viz.,

https://news.ycombinator.com/item?id=13224864

Re: Emacs 26.1 released

#100

Post by krylon »

phillord wrote: post #97
krylon wrote: post #30

Completely OT, but I remember when building Emacs was like "there goes my afternoon". On my current desktop (which is kind of snazzy, I admit), it takes less than 30 seconds wall clock time. This is one aspect of The Future(tm) I definitely appreciate. ;-)

Build from the source tarball, or a bootstrap build? For me, I can't get the later much below 10 minutes and often much longer.

My desktop is a Ryzen 1700, 8 cores, 16 threads. So I run "make -j16". =D

    $ make -j16
    make -j16  156,14s user 9,37s system 714% cpu 23,166 total
Post reply on HN