Toward a "modern" Emacs
The May 2020 discussion focused on restoring the popularity that Emacs is felt to have enjoyed in the past. It could well be that there are more Emacs users now than at any time in the past but the editor's share of the total computing user base has clearly shrunk over time. The current discussion has a similar but different focus: attracting new users to Emacs, an editor that is widely seen as being outdated and as having a difficult and intimidating learning curve.
A more modern Emacs
The initial thread was started by "Ergus" on September 6 as a request to consider some changes for the Emacs 28 release. Rather than focus on new features, though, Ergus proposed making some existing features more accessible:
Many of the suggestions reverberated through the following discussions,
starting with the idea that the default theme for Emacs should be
improved. In particular, Ergus suggested the adoption of a dark theme by
default "to make Emacs feel more modern
". The discussion
often returned to the idea that Emacs needs a more "modern" look and feel,
though there was, understandably, some difference of opinion over what
"modern" means.
A default dark theme may not be in the future, leading one to think that there may yet be hope for the world in general. But there does seem to be general agreement that Emacs could benefit from a better, more centralized approach to color themes, rather than having color names hard-coded throughout various Elisp packages. From that, a proper theme engine could be supported, making dark themes and such easily available to those who want them.
There was some discussion of adopting the Solarized color palette in particular. As Dmitry Gutov pointed out, though, Solarized makes for a rather low-contrast experience; a look at this screenshot of Emacs with Solarized colors makes that clear enough.
Another area where Emacs is insufficiently "modern", it seems, has to do with keyboard and mouse bindings. On the keyboard side, users have come to expect certain actions from certain keystrokes; ^X to cut a selection, ^V to paste it, etc. These bindings are easily had by turning on the Cua mode, but new users tend not to know about this mode or how to enable it. Many participants in the discussion said that this mode should be on by default.
That, of course, would break the finger memory of large numbers of existing Emacs users, who would be unlikely to appreciate the disruption. Or, as Richard Stallman put it:
For better or worse, though, the "newer editors" appear to have won out in this regard. The default bindings in Emacs may not change anytime soon, but that doesn't mean Emacs can't provide a way for users to get that behavior without needing to learn Lisp first.
The situation with mouse behavior is similar; as several participants in the discussion pointed out, users of graphical interfaces have come to expect that a right-button click will produce a menu of available actions. In Emacs, instead, that button marks a region ("selection"), with a second click in the same spot yanking ("cutting") the selected text. Many experienced Emacs users have come to like this behavior, but it is surprising to newcomers. The right mouse button with the control key held down does produce a menu defined by the current major mode, but that is evidently not what is being requested here; that menu, some say, should present global actions rather mode-specific ones.
Stallman suggested
offering a "reshuffled mode
" that would bring the context menu
to an unadorned right-button click, and which would add some of the
expected basic editing commands there as well. This would be relatively
easy to do, he said, since mouse bindings are separate from everything
else. Besides, as he noted, the
current mouse behavior was derived from "what was the standard in X
Windows around 1990
"; while one wouldn't want to act in haste, it
might just be about time for an update.
Discoverability
In general, Emacs has all of the capabilities that new users might wish to
have (and more), but those capabilities can be difficult to discover and use. So a
number of the proposed changes had to do with easing discovery. This came
as an apparent surprise to some Emacs developers, who have long thought of
the menu bar at the top of each window as being an easy way for users to
discover features. But evidently it is common to disable the menu bar for
Emacs; as Gregory Heytings put
it, "menus are not 'modern'
". To be "modern", an
application must either attach its menus to the right mouse button or, at
most, provide a "hamburger menu" from a single button.
Emacs could certainly move to that mode, at least until menu bars are
fashionable again. But there are other ideas for improving discoverability
circulating as well. One of those would be to offer a "guided tour" to new
users upon the first invocation of the editor that would quickly introduce
core Emacs features; this would be an enhancement of the tutorial that
exists now. There was also a discussion of producing a series of videos,
or perhaps just making use of the many videos that exist now. Stefan
Monnier suggested
short videos to match the perceived attention span of young users,
"ideally funny and sexy, maybe with a cat
".
A step beyond the guided tour would be some sort of "configuration assistant" that would run on the first invocation of Emacs. It could offer tours, but it would also give the user the opportunity to configure the editor in ways that might better match their expectations. Features like Cua mode could be enabled, for example, mouse bindings adjusted, and a depressing dark theme selected without the need to type a single parenthesis. That might be enough to overcome the initial shock of exposure to Emacs for many new users.
One other suggestion that was raised frequently is to enable various modes that are not turned on by default in Emacs; indeed, several of them are not shipped with Emacs at all. For example, Ibuffer is generally seen as superior to the standard Emacs buffer list, so many think it should replace the standard list. The Emacs "undo" mechanism is more capable than what is provided in many other editors, but it is also seen as difficult to use; some users think that the undo-tree mode makes undo easier and should be shipped with Emacs and enabled by default. There are several modes that enhance the editor's command-search and autocompletion capabilities, including Ivy, Helm, and Ido, among others. Many of these, it is argued, provide behavior more in line with current expectations and improve discoverability; one of them should be adopted and made the default.
Attracting developers
One problem with many of these packages is that they are not actually a part of GNU Emacs. Changing that would often require the author to sign copyrights over to the Free Software Foundation, which is not something all authors are willing to do. Similar problems arise with many of the derivative Emacs "distributions", such as spacemacs or Doom, which have clearly eased the path into Emacs for some users. Some of the ideas found in these distributions may well merit inclusion in Emacs, but that does not happen. Emacs maintainer Eli Zaretskii complained that the creators of these distributions do not contribute their work back.
This points to one idea that did not really come up in the discussion, but
which should be considered: part of the key to making Emacs more attractive
to users might be making its development community more attractive to
contributors. Adopting some of the more forge-oriented tools favored by
younger developers might help in this regard, as might a less centralized
governance model. Emacs remains an old-style GNU project, a fact which
clearly grates on
its developers at times. Increasing the relevance of Emacs in the coming
years is going to require more than new key bindings and some cat videos;
it is likely to require attention to improving the experience at all
levels.
Posted Sep 25, 2020 17:03 UTC (Fri)
by horen (guest, #2514)
[Link]
Posted Sep 25, 2020 17:55 UTC (Fri)
by smoogen (subscriber, #97)
[Link] (52 responses)
```
In the end, making emacs into looking like all the current code editors like VScode and such does not fix the core problem: to have an editor for developers, you have to have the environment developers want to work in. Frankly I don't see that changing because a lot of people are happy with what they have. The only way I see it changing is people doing the hard work of making a new community that does those things, gets changes done and sees if new people are interested in having a completely programmable editor written in what is now an esoteric language.
[Says the person who has been using emacs since 1987 ... but finds no interest in training new people in it anymore.]
Posted Sep 26, 2020 1:31 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (51 responses)
Spot on, thank you. A "noob-friendly" mode wouldn't hurt (as long as long time users can disable it) but you really don't need a very large user base for a project like this to strive. It's much more important to make super easy to contribute for the _users you already have_. I've been using Emacs for a couple decades and I found the process to submit a one-line patch ridiculously outdated, see my other comment below.
With delusional friends like these, Emacs needs no enemy:
> "It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs."
I think I read once one of the designers of the GPL stating that copyleft, copyright assignment and other restrictions wouldn't be needed in a perfect world with BSD licenses everywhere. Something like that.
The world has completely changed since the copyleft was invented. It's not "perfect" because closed source still exists (always will) but open source is absolutely "everywhere you look" and a massive lot is NOT copyleft. The FSF people have won but they haven't noticed because of their idealism/dogma. So we're now in this crazy situation where it takes more effort to make open-source contribution to FSF projects because of paperwork and refusal to use any tool that is not Kosher.
Posted Sep 26, 2020 1:46 UTC (Sat)
by pizza (subscriber, #46)
[Link] (17 responses)
The "FSF people" may have managed to change the world, but they have not "won" -- "Open Source" is not "Free Software".
Posted Sep 26, 2020 2:17 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
> The "FSF people" may have managed to change the world, but they have not "won" -- "Open Source" is not "Free Software".
I meant: a massive lot is not copyleft and either BSD, MIT, Apache, etc. which are all Free Software. "More free" than GPL actually because you're not forced to do good things; you're also allowed to do "bad" things.
Also, they did not "won" also because open source was inevitable anyway; at best they accelerated it. With "they won" I was just trying to be stylish I think you got my point.
Posted Sep 26, 2020 4:03 UTC (Sat)
by rsidd (subscriber, #2582)
[Link] (15 responses)
Posted Sep 26, 2020 6:08 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (14 responses)
Also, the real world definition is that almost all OSes that run on hardware and call themselves "open source" include nonfree code. OSes that call themselves free software are much more likely to mean all the code is free software. The free software definition explicitly addresses which code to consider, and its put in practice in https://www.gnu.org/distros/common-distros.en.html, https://ryf.fsf.org/about/criteria, and https://www.gnu.org/philosophy/javascript-trap.en.html.
An exception to this rule is 8 bit arduino's which are often called open source and are fully free software (but the arduino development environment includes optional nonfree code).
Posted Sep 26, 2020 12:17 UTC (Sat)
by pizza (subscriber, #46)
[Link] (13 responses)
In the real world, I've been forced to use a lot of proprietary software that is built on top of "open source" codebases. This includes multiple android devices and several variations of LLVM. After all, _I_ don't have the source code to what is actually running.
Posted Sep 26, 2020 18:36 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (12 responses)
Of course I'm a bit slow: if something needs to be rephrased and discussed a million times then it's likely not just because everyone's stupid. Discussions that tend to get heated are also much more often triggered by misunderstandings than disagreements. Finally, who expects good names from software engineers? :-)
So the key concept/idea behind "free software" or more specifically "copyleft software" is transitivity: making sure not just the users but also _the users of the users_ are free to do what they want. This of course implies the first users are _less_ free to do what they want which means "free" is self-contradicting. Boom.
Even before someone wrote that "my freedom stops where yours begin" we knew freedom was a messy concept best avoided when possible. For some fun search for "weaponized first amendment".
This also seems like a classic case of trying to avoid a technical and unusual but very smart and extremely accurate term "copyleft" for the fear of confusing readers, dumbing it down and confusing everyone much more. And then not wondering what went wrong.
I will stop referring to GPL software as "free software" from now on, it will help save a fair amount of digital ink. "Copyleft software" it is.
PS: not sure yet how to best name BSD-like licenses. "permissive" is very vague.
Posted Sep 26, 2020 18:39 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link] (2 responses)
(The other way I can think of is to describe the GPL as "socialist", the BSD and MIT licences as "liberal", and proprietary licences as "reactionary", but that doesn't work very well.)
Posted Sep 27, 2020 8:35 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
GPL frees the *user*, BSD frees the *developer*.
Cheers,
Posted Sep 27, 2020 16:50 UTC (Sun)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 26, 2020 20:09 UTC (Sat)
by smcv (subscriber, #53363)
[Link]
Using "free software" to refer only to copyleft licenses and "open source" to refer to permissive licenses seems really confusing, since it's in conflict with the way the originators of those terms use them: the FSF considers both copyleft and permissive licenses to be free software, and the OSI considers both copyleft and permissive licences to be open source.
The free software movement and the open source movement (inasmuch as either of those is monolithic) have different goals and different focuses, and perhaps free software is more closely aligned with copyleft while open source is more closely aligned with permissive licensing, but I think a lot of people who consider themselves to be part of one community and not the other would agree that both styles of licensing have their place (although probably not on the specifics of which one is more suitable for a particular project).
Posted Sep 27, 2020 7:46 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (6 responses)
Posted Sep 27, 2020 17:05 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (5 responses)
... which is amazing considering he literally invented the entire "less-free-for-developers and more-free-for-users" software category, and probably the super smart "copyleft" word for it too. How come _he_ did not drop the super confusing "free" terminology? All his followers would have... followed, as they do when they use "free software" now, which helps feeding the never ending stream of debates where the basics seem to be re-explained over and over again.
Posted Sep 27, 2020 17:15 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (4 responses)
In short, this entire thread is a red herring, based on a misunderstanding of "free software".
Posted Sep 27, 2020 17:26 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Misunderstanding as in the gazillions other threads before it and in all the future ones too. I'm impressed by how quickly you found and posted the references, you must be really used to that :-)
Posted Sep 28, 2020 2:38 UTC (Mon)
by jwarnica (subscriber, #27492)
[Link]
The problems is that RMS defines community as a) "the keybindings I personally enjoyed in 1975 long before industry and sanity discarded the concept of 'cording keyboard' " b) a particular non-technical and highly idealistic political philosophic and c) if yoiur a women, falling over yourself to get to me.
Which is, I grant, a *particular* community, but not one that is welcoming to pretty much anyone who has first used a computer since either the IBM PC or Apple MAC was introduced.
Posted Sep 29, 2020 10:19 UTC (Tue)
by smcv (subscriber, #53363)
[Link] (1 responses)
Regarding the difference between free software and copyleft: free software (or software freedom if you prefer) is a goal, but copyleft is one of several possible strategies for achieving that goal (permissive licensing is another). Copyleft is closely associated with the term "free software" because the FSF has chosen to use copyleft as their main strategy, but it isn't actually their objective.
Posted Oct 5, 2020 21:05 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
... and also avoided any copyleft/permissive ambiguity - thanks!
BTW "Software Freedom Conservancy" is an exceptionally clear name.
While their top goal seems to be copyleft enforcement, funny enough they don't seem to request copyright assignment before sending a patch. Their website also seems less focused on philosophy and more on getting copyleft things done but maybe that's just my impression.
Posted Oct 1, 2020 19:36 UTC (Thu)
by ecree (guest, #95790)
[Link]
I believe the canonical term is 'copycenter'. See http://www.catb.org/jargon/html/C/copycenter.html
Posted Sep 26, 2020 3:24 UTC (Sat)
by cmonsanto (subscriber, #96651)
[Link] (4 responses)
> > "It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs."
Same mindset that kept Emacs on Bazaar well after the wider community standardized on Git.
> So we're now in this crazy situation where it takes more effort to make open-source contribution to FSF projects because of paperwork and refusal to use any tool that is not Kosher.
What bothers me the most about this situation is that there's nothing to even protect. Can you imagine a contentious lawsuit over Emacs source? What, is a router going to hide a modified elisp interpreter a-la busybox?
Posted Sep 26, 2020 4:21 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (3 responses)
Posted Sep 26, 2020 5:03 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
More seriously: many companies do try to avoid the GPL as much as they can and the GPLv3 even more. However there's zero evidence that they care about who holds the copyright. Imagine a legal department having the time and resource to "profile" open source copyright authors...
Posted Sep 26, 2020 6:35 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (1 responses)
There is a long history and plenty of evidence regarding FSF and MS legal department.
Posted Sep 26, 2020 17:01 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
To be clear: did Microsoft struggle with the FSF in the past? I bet. Did Microsoft have rules to deal with open source or the GPL? Yes of course. Still has, just like any other software company. What I assumed and meant is: Microsoft Legal never explicitly instructed its employees to deal with "FSF software" differently from any other GPL software.
Posted Sep 26, 2020 9:35 UTC (Sat)
by Sesse (subscriber, #53779)
[Link] (22 responses)
Well, yes. Emacs has a problem: It can cater to new users, or it can cater to RMS' personal preferences. Whether explicitly or implicitly, the project is choosing the latter at almost every turn, and thus can not hope to attract many of the former.
Posted Sep 26, 2020 12:38 UTC (Sat)
by pizza (subscriber, #46)
[Link] (8 responses)
s/RMS/existing users/
and also, s/RMS/existing developers/
Granted, that doesn't invalidate your point. However, RMS's point is also valid; it's not wise to alienate the current user (and more importantly, developer) base, in favor of mythical hordes of new users (and developers) that experience shows us aren't likely to ever materialize.
Posted Sep 26, 2020 12:46 UTC (Sat)
by Sesse (subscriber, #53779)
[Link] (7 responses)
Interestingly enough, since keybindings were discussed; vim has an even higher barrier to entry (I mean, if you think C-k for cut and C-y for paste is bad, how about vim's modes?), yet somehow manages to stay somewhat relevant while emacs is dwindling. (E.g. it ties IntelliJ for #4 in StackOverflow's survey over development tools, with five the popularity of emacs.)
Posted Sep 26, 2020 17:09 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (1 responses)
I suspect there's a sizable "niche" of users who like a modal editor. Because it's a bit of a niche there's less room for competition so vim is able to fill it completely (and to your point: probably because they listen to all their users too). I don't think there is any another modal _and_ popular editor. Because this niche is not so small, it ends up #4 on stackoverflow.
My 2 cents.
Posted Sep 26, 2020 20:30 UTC (Sat)
by cpitrat (subscriber, #116459)
[Link]
Posted Sep 26, 2020 20:26 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Sep 29, 2020 6:42 UTC (Tue)
by dgm (subscriber, #49227)
[Link]
Posted Oct 1, 2020 19:41 UTC (Thu)
by ecree (guest, #95790)
[Link] (2 responses)
Well, you don't *have* to. You could do what I did and learn ed instead, which means you don't have to look at ugly Vim, and as an additional bonus you get to be insufferably smug. (Well, until someone shows up with butterflies.)
Posted Oct 1, 2020 20:47 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 1, 2020 20:58 UTC (Thu)
by ecree (guest, #95790)
[Link]
Posted Sep 26, 2020 19:32 UTC (Sat)
by mvar (guest, #82051)
[Link] (12 responses)
i see that response by rms as more tongue in cheek, meaning that everyone claims that emacs has those weird combinations for copy/cut/paste when actually it predates these by many, many years..So why should emacs adapt and change how it works based on some trend that appeared later? rms is stubborn at times, i just don't think this comment of his is indication of arrogance, it's just stating the facts. On the other hand his stance about the "NO WARRANTY" message in the splash screen (last link in the article), ugh... *sigh*
Posted Sep 26, 2020 20:49 UTC (Sat)
by Sesse (subscriber, #53779)
[Link] (11 responses)
In case it's not obvious: Because the Ctrl-X/C/V bindings are clearly _better_. They can be done with the left hand without moving it while the right hand is using the mouse, which is cumbersome for Ctrl-K/Y.
Of course, due to inertia, not everything is worth changing. And Emacs' problem is not first and foremost about those specific bindings. But it is a symptom.
Posted Sep 27, 2020 2:15 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (4 responses)
Posted Sep 27, 2020 8:16 UTC (Sun)
by Sesse (subscriber, #53779)
[Link] (3 responses)
Posted Sep 28, 2020 11:40 UTC (Mon)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Sep 29, 2020 7:32 UTC (Tue)
by k8to (guest, #15413)
[Link] (1 responses)
Posted Oct 1, 2020 3:21 UTC (Thu)
by jasone (subscriber, #2423)
[Link]
Posted Sep 27, 2020 6:10 UTC (Sun)
by rodgerd (guest, #58896)
[Link] (1 responses)
Indeed, and it's one that seems to expose a fundamental division in both the FSF and the GNU project generally: the people who would like very much to enable the broader world to have the ability to use free software to do the things that matter to them, and the people who are interested in the Cult of Richard.
Posted Sep 27, 2020 6:40 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Sep 29, 2020 14:57 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link] (2 responses)
Posted Sep 29, 2020 15:59 UTC (Tue)
by jem (subscriber, #24231)
[Link] (1 responses)
Posted Sep 29, 2020 17:53 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link]
Posted Oct 13, 2020 17:18 UTC (Tue)
by debacle (subscriber, #7114)
[Link]
Or the other way around: It is cumbersome to use the mouse with Emacs key bindings. I assume, that many Emacs users do not use the mouse much. I don't even have one, only a touchpad, centered in front of the space bar.
Posted Sep 28, 2020 11:00 UTC (Mon)
by flussence (guest, #85566)
[Link]
It's not about idealism any more, it's blind worship of religious scripture. RMS is high on his own product.
Posted Sep 28, 2020 12:30 UTC (Mon)
by MrWim (subscriber, #47432)
[Link] (3 responses)
I think this misunderstands the aims of the FSF. Really it's not about software, it's about people (aka users). Does the software restrict the user in some way? Free software licences including copyleft or BSD style are a means to that end, rather than an end in itself.
So: if there's more free software out there, but people have less control then overall this is seen as a loss.
I'm not saying that I completely agree with the FSF, but I think their position is consistent with their purpose (or idealism/dogma as you put it).
There was a link posted to LWN a few years ago to this effect. Something about there being more open-source software out there, but even more proprietary software build upon it. It was by some bigshot like Eben Moglen. I'd love to link to it but I can't find it now.
Posted Sep 28, 2020 14:27 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (1 responses)
https://archive.fosdem.org/2019/schedule/event/full_softw...
Posted Sep 28, 2020 15:44 UTC (Mon)
by MrWim (subscriber, #47432)
[Link]
Posted Sep 29, 2020 7:37 UTC (Tue)
by k8to (guest, #15413)
[Link]
I think the ideological freedom of the users is important, and that FSF correctly identified this way back when and still have a useful mission to share that seed idea. I just don't think that browbeating users who want to make reasonable changes that do not actually harm those ideological ideas serves that mission.
Posted Sep 25, 2020 18:14 UTC (Fri)
by iabervon (subscriber, #722)
[Link] (1 responses)
This would allow for proper handling of features that are objectively improvements in behavior but counterproductive for people who developed habits without them. For that matter, a lot of behaviors could be tied (by default) to a system where users can tell Emacs go to a more recommended configuration when the users want to devote some time to retraining. This also gives a path to softening the learning curve, where the default modern configuration is something intuitive but inefficient, and users who do that particular thing enough to care can put in the time when they choose to and get comfortable with the unintuitive efficient way. I like to remember that all of us are casual users of nearly everything, experts at a few things we've intentionally put time into, and idiosyncratic about some other things we've never really thought about. Having a system that does what the user wants for each of these cases is only possible by having different behavior depending on the user's history and changing when the user wants to.
Posted Sep 25, 2020 19:52 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link]
> It would create a different editor that we Emacs users would never switch to.
And, I'd say, yes, that's still probably the best way forward. I don't think doing it multiple times as you suggest is a good idea, because it is a lot of work to maintain multiple defaults and all have them all work well. There are people are doing it already https://www.emacswiki.org/emacs/StarterKits. I suspect a good way forward for modernizing emacs is for one of those projects to make a concerted effort to get merged upstream and maintain the code in upstream.
Posted Sep 25, 2020 18:57 UTC (Fri)
by tdz (subscriber, #58733)
[Link] (7 responses)
How much of emacs is the editor, and how much is the environment? Could they have an entirely separate, 'modern' interface on top of the Lisp interpreter and sell it as 'emacs-light'.
Posted Sep 25, 2020 21:37 UTC (Fri)
by wfp5p (subscriber, #56918)
[Link]
Posted Sep 26, 2020 4:40 UTC (Sat)
by cozzyd (guest, #110972)
[Link] (1 responses)
(actually, as a vim user, the main suggestion I'd have for emacs is to have evil mode by default =P).
Posted Sep 26, 2020 8:08 UTC (Sat)
by MKesper (subscriber, #38539)
[Link]
Posted Sep 26, 2020 11:24 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link] (3 responses)
Emacs is used because of accumulated trove of elisp code that covers everything under the Sun.
Read the elisp manual and you'll see that the API to manipulate UI (buffers, windows) is in the heart of it — make a new, incompatible, UI and you'll lose compatibility with all the elisp code written ever except libraries.
Emacs with new incompatible UI is no better than an outdated quirky Lisp VM. One can easily take Clojure and build an editor from it, the results will be identical, except that the language is better.
Posted Sep 26, 2020 11:59 UTC (Sat)
by tdz (subscriber, #58733)
[Link] (2 responses)
Posted Sep 26, 2020 15:38 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link]
Posted Sep 26, 2020 16:29 UTC (Sat)
by khim (subscriber, #9252)
[Link]
I will try to say what others have said again. Yes, Emacs is mostly a development platform — and API for that development platform is Emacs UI. That's the same issue Firefox developers faced and the same issue which made Chrome developers to only offer very limited extensions API: if you give developers an option to change, basically, anything in your app… then suddenly all possible changes in the app become impossible. That's why, ultimately, what we have now, today, is not Emacs 28, but, in reality Emacs 1.28: the major part of Emacs version number was dropped years ago because you couldn't radically change anything in Emacs. You can only extend it, not change it.
Posted Sep 25, 2020 18:59 UTC (Fri)
by josh (subscriber, #17465)
[Link] (22 responses)
That wouldn't preclude further customization, just set a wide swath of defaults, and allow people who care about the classic defaults to just ignore proposals to change the modern defaults.
I think the conclusion that Emacs needs to sort out its development model and development community, though, is indeed an accurate assessment of the root of the problem. It's not (just) about using a better development interface. It's about allowing for "drive-by" contributions, dedicating time to reviewing *other people's* patches who don't have or want commit access, and otherwise helping people wade into development.
Posted Sep 25, 2020 19:58 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (21 responses)
It's been a while, but I've had simple and complex patches quickly reviewed and merged. What are you basing this on?
Posted Sep 25, 2020 20:35 UTC (Fri)
by josh (subscriber, #17465)
[Link] (20 responses)
Requiring people to submit paperwork first kills casual contribution; you have to be fairly dedicated to get past even that hurdle.
I've also seen patches go months without any response at all.
Beyond that, I'm basing it on various anecdotes and observations, having followed the emacs-devel list for a while. In general, there are a number of things that discourage contribution, especially casual contribution. It's not that people aren't interested. It's that the reaction to many people who are interested radiates "go away".
It's absolutely the job of a maintainer to say "no" quite often. But given a good project and a well-meaning contributor, you don't want to just end it with a flat "no", you want to steer it towards "that approach won't work, here's why, but let's talk about how to solve the underlying problem that led you here in the first place". Leaving the last part out can turn it into "go away and don't come back".
Posted Sep 25, 2020 20:46 UTC (Fri)
by mohg (guest, #114025)
[Link] (1 responses)
There are around 1900 people listed in the AUTHORS file for Emacs.
Posted Sep 25, 2020 21:23 UTC (Fri)
by corbet (editor, #1)
[Link]
Posted Sep 26, 2020 1:09 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (13 responses)
I recently tried to "promote" myself from seasoned user to contributor. Learned a bit more eLisp and some basic troubleshooting techniques. Root-caused a bug or two in tramp, pinpointed what was wrong in the code and started to make some code changes.
Then I discovered I have to surrender copyright, submit paperwork and subscribe to some mailing-lists (13 different ones listed at https://savannah.gnu.org/mail/?group=emacs...) I'm not interested in configuring an email filter so I can ignore emacs-devel discussions, I just want to file a bug and git push a patch to something that runs CI.
I heard the VSCode equivalent of tramp rocks. I'm now seriously considering abandoning a couple decades of Emacs muscle memory.
Posted Sep 26, 2020 1:34 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (7 responses)
That is not true, I wonder where you got that. Subscription has and never will be required. Just email your patches to emacs-devel@gnu.org, email bug reports to bug-gnu-emacs@gnu.org. People will reply to you.
If you send email from an address the list has never seen before, it can take a few hours before a human looks at it and sends it to the list. That happens regardless of subscription status.
Posted Sep 26, 2020 1:40 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 26, 2020 2:09 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (5 responses)
> That is not true, I wonder where you got that.
That's great, thanks for correcting me but I'm still not interested in using email "the old way". I want to select myself which code reviews and which bugs send me email and I want all the discussion about one particular series to be easy to find in one place. It does not necessarily imply a web interface, it only implies a "modern" database. I haven't tried this myself but I heard some people use github from... Emacs most of the time! http://wikemacs.org/wiki/Github
PS: I "got that" because that is (used to be?) the most common expectation with email-based projects. I (genuinely) wonder where you got the correct information.
Posted Sep 26, 2020 2:20 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (2 responses)
I can't remember exactly where I figured out that 99.5% of gnu.org and nongnu.org lists don't require subscription to post, probably after I became an administrator of them, which is not a good sign.
Posted Sep 26, 2020 2:36 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link]
Posted Sep 26, 2020 17:21 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Yes please.
I suspect the most obvious and common rationale for requiring mailing-list subscription is mitigating spam, which code review databases keep under control by requiring a user account, which is admittedly their biggest road bump for "drive-by" contributors. Security versus usability: always the same trade-off.
The user account road-bump is largely mitigated thanks to federation: I mean for instance you can re-use your launchpad and many other accounts on a number of "foreign" sites.
Posted Sep 26, 2020 2:40 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (1 responses)
Posted Sep 26, 2020 17:44 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Posted Sep 26, 2020 6:40 UTC (Sat)
by eliz (guest, #94829)
[Link] (4 responses)
On 1/3 true: the paperwork, and it's a one-time thing.
The rest is simply misunderstandings: you don't surrender any copyright (the legal paper you get at the end of the paperwork explicitly says that the FSF grants back to you the copyright), and you don't need to subscribe to any mailing lists, because submitting an issue makes sure you are CC'ed on any messages posted to that issue.
Posted Sep 28, 2020 9:47 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (3 responses)
Any paperwork is a real hassle for me, however; of my employers over the last 20 years, one would require approval for all OSS contributions, the others only require that I notify them of the contribution and that it's licensed under one of a list of acceptable licences (which include GPLv3). For contributions to most projects, this is enough - I can publish code where my employer is the copyright holder under a Free or Open source licence, they can pull it in, everyone's happy.
However, once you require copyright assignment paperwork (as the FSF does), the hassle level for me skyrockets; I have to get hold of the documentation, take it to legal, give them time to review it, schedule time with legal to discuss what the paperwork means, get legal to produce a document confirming I'm allowed to sign it without compromising my employment, sign it, get legal to sign it, and then return it to the originator. That's an awful lot of work if my patch is going to be a small thing and I don't expect to repeat it any time soon (so may move onto another employer and have to repeat the copyright assignment dance for the next patch).
So, while it might be a one-off per employer for me, it's a lot of effort to go through when I'm not doing a "big" contribution; and because I'm put off from doing small contributions, upstream never gets the chance to encourage me to make bigger ones.
Posted Sep 28, 2020 12:12 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (2 responses)
Posted Sep 28, 2020 13:06 UTC (Mon)
by farnz (subscriber, #17727)
[Link] (1 responses)
Even on code where I own the copyright, I still have to go via my employer to get permission to sign copyright assignment forms, because of the risk of a conflict of interest between the person I'm assigning copyright to, and my employer.
And, of course, such a negotiation involves all the hassle of going through legal to get a contract change *and* then I have to go through all the hassle again to sign a copyright assignment form. Why would I bother doing any of this for a small change?
Posted Oct 2, 2020 10:37 UTC (Fri)
by kpfleming (subscriber, #23250)
[Link]
So, if you are employed as a software developer, you will need to get your employer to sign an FSF document either way: either a copyright assignment, or a disclaimer.
Posted Sep 26, 2020 2:11 UTC (Sat)
by IanKelling (subscriber, #89418)
[Link] (3 responses)
No one has ever been required to submit paperwork FIRST. You submit a patch, it gets feedback, it may require revisions, if it gets accepted and its more than 15 lines of non-trival changes, then you assign copyright for it to be added to the repo. While that process happens, nothing is stopping you from working on and submitting more patches. Often people get multiple patches accepted and never assign copyright because they are only a few lines. And assigning copyright is pretty much just replying to an email with your name and address. If you work somewhere doing software or something, you send an email to your company. 2 emails.
This may have changed, but at least until recently, if employees at microsoft wanted to submit a patch to any free software at all, it had to be reviewed by their 2nd or 3rd level boss, perhaps a legal team, a much much bigger ordeal. Let's complain about that kind of thing instead.
Posted Sep 26, 2020 2:21 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (2 responses)
Let's not because it's really bad but totally off-topic.
Posted Sep 26, 2020 6:42 UTC (Sat)
by eliz (guest, #94829)
[Link] (1 responses)
Hey, you started this "off-topic" stuff.
Posted Sep 26, 2020 17:41 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Open https://lwn.net/Articles/832311 and search for "Microsoft".
Posted Sep 25, 2020 19:44 UTC (Fri)
by mtk (subscriber, #804)
[Link] (25 responses)
right now emacs supports LSP if you know how to pull it out of MELPA. but the number of available LSP servers for each language alone is confusing. and the number of complimentary libraries and their overlapping functionality is *bewildering*.
it would be useful if LSP support became part of the base. and if someone focused on providing a best-of-breed out-of-the-box LSP/tool setup that worked for all of the major languages
Posted Sep 25, 2020 20:49 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (4 responses)
bright backgrounds are (mostly) fantastic on reflective surfaces (books etc), but IME they're horrible on emissive surfaces (like computer screens).
Posted Sep 25, 2020 21:23 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (3 responses)
Yes, my emacs is in "dark mode" by default.
Posted Sep 26, 2020 4:47 UTC (Sat)
by felixfix (subscriber, #242)
[Link] (2 responses)
Posted Sep 26, 2020 13:01 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (1 responses)
Posted Sep 26, 2020 15:01 UTC (Sat)
by felixfix (subscriber, #242)
[Link]
Posted Sep 25, 2020 21:52 UTC (Fri)
by mina86 (guest, #68442)
[Link] (19 responses)
Posted Sep 25, 2020 23:33 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (18 responses)
Autocompletion, jumping to definitions, etc. are all really good in Emacs. (OK, you need to use helper programs like etags for navigating to definitions.)
The problem is that some features require setup, and others are not obvious... I didn't know about Emacs's dynamic autocompletion using M-/ until I'd been using it for about 10 years. (I'm
30 years in on Emacs now and not switching editors any time soon...)
Posted Sep 26, 2020 11:27 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link] (16 responses)
Posted Sep 26, 2020 13:00 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (2 responses)
Posted Sep 26, 2020 15:36 UTC (Sat)
by dottedmag (subscriber, #18590)
[Link] (1 responses)
Posted Sep 26, 2020 21:02 UTC (Sat)
by dskoll (subscriber, #1630)
[Link]
I have not done extensive refactoring work on large codebases. I have done Linux kernel driver development and development of several quite large systems in languages including C, C++, Perl and PHP. And Emacs has worked very well for me.
Posted Sep 27, 2020 9:52 UTC (Sun)
by pgdx (guest, #119243)
[Link] (10 responses)
You of course rebase/reorder/reword/squash your history before publishing it if necessary.
Posted Sep 27, 2020 10:48 UTC (Sun)
by dottedmag (subscriber, #18590)
[Link] (8 responses)
I don't understand how in 2020 the index is not *always* up-to-date. We've got so much computing power, and we still have to run tools manually over a dataset (source code) that is sized in megabytes, and is modified less than a kilobyte per second?
Posted Sep 27, 2020 11:55 UTC (Sun)
by cmonsanto (subscriber, #96651)
[Link] (7 responses)
There's nothing to understand, it's a technically inferior solution. It was a hassle decades ago, and unacceptable in the age of LSP.
Posted Sep 27, 2020 11:59 UTC (Sun)
by dottedmag (subscriber, #18590)
[Link]
Posted Sep 27, 2020 14:27 UTC (Sun)
by dskoll (subscriber, #1630)
[Link] (5 responses)
Posted Sep 27, 2020 15:49 UTC (Sun)
by cmonsanto (subscriber, #96651)
[Link] (4 responses)
Posted Sep 28, 2020 0:32 UTC (Mon)
by dskoll (subscriber, #1630)
[Link] (3 responses)
Never having used VSCode before, I gave it a whirl. Fired it up on a directory containing some C sources, installed the C/C++ addon, and...
The cross-referencing didn't work. Every time I tried to jump to the definition of a function, it took me to the declaration instead. So much for "Just Works (tm)".
Posted Sep 28, 2020 5:14 UTC (Mon)
by jem (subscriber, #24231)
[Link] (1 responses)
Posted Sep 28, 2020 5:24 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
There's no incentive for MS to sabotage VSCode, they want to make sure developers are using Microsoft's tools that conveniently have all these nice out-of-the-box integrations with Microsoft services.
I have no idea what went wrong for you, but my VSCode works just fine with navigation and refactoring support.
Posted Sep 28, 2020 12:04 UTC (Mon)
by dskoll (subscriber, #1630)
[Link]
Posted Sep 28, 2020 13:08 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 1, 2020 11:54 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (1 responses)
Posted Oct 1, 2020 14:48 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Posted Oct 4, 2020 11:32 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
Never heard about it over the last 25 years. I'm using M-, for tags though. Will have a look, thanks.
Discoverability of features is absolutely horrible there. Just enabling popups a-la "did you know" on startup would promote a lot of them. Of course it would require that they are actually usable without having to blindly copy-paste config sections from stackoverflow...
Posted Sep 25, 2020 21:38 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (22 responses)
If I received a request to CLA my already-released FOSS project, I would likely WONTFIX it in five seconds. You have the code, it is fully GPL-compliant, and (as a result) it's already licensed under the same terms as upstream. There is no actual legal barrier to pulling it. If you want a copyright assignment anyway, you can pay me (so that I can hire a lawyer and ask them to figure out my obligations w.r.t. my employer, among other complicated and distressing legal issues). I imagine some of the maintainers of these projects would take a similar stance.
Frankly, I'm not sure GNU Emacs is in a position to continue making this demand, GNU policy notwithstanding. CLAs have, in recent years, been increasingly used by for-profit companies to lock away formerly-FOSS code behind non-FOSS licenses, or to otherwise cause problems for FOSS. See for example Oracle, Commons Clause, the SSPL, etc. How do I know that the FSF isn't going bankrupt in the next 10+ years? How do I know some random company isn't going to buy their stuff up and relicense everything to proprietary?
They have the right to conduct their internal development process however they want. They do not have the right to continue being relevant, especially if they choose to ignore the current state of the industry.
Posted Sep 25, 2020 22:14 UTC (Fri)
by IanKelling (subscriber, #89418)
[Link] (21 responses)
> ignore the current state of the industry
Give me a break. Here's a related link.
Posted Sep 25, 2020 23:30 UTC (Fri)
by sfeam (subscriber, #2841)
[Link] (3 responses)
Posted Sep 26, 2020 6:46 UTC (Sat)
by eliz (guest, #94829)
[Link] (2 responses)
You need to read the assignment agreement text to understand that.
Basically, you assign the copyright to the FSF, and the FSF gives it back to you, so that you still have full copyright of the code you wrote, and can do whatever you want with it, including distributing it on whatever terms.
The paperwork is important only to the code that is part of Emacs, not to your original work. Authors always have full rights for the code they wrote.
Posted Sep 26, 2020 11:13 UTC (Sat)
by hvd (guest, #128680)
[Link] (1 responses)
Posted Oct 2, 2020 10:42 UTC (Fri)
by kpfleming (subscriber, #23250)
[Link]
You assign your copyrights to the FSF, and they grant you a broad license (beyond the terms of the GPL or any other FSF software license) to continue making use of your contributions in any way you wish (as long as that use does not conflict with the FSF's use of the same contributions).
Posted Sep 25, 2020 23:55 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
You missed the word "bankruptcy." If they go bankrupt, they may have no choice in the matter. This is precisely what happened to Sun.
> And there is a barrier to pulling your code: enforcing copyright when you don't own the copyright is significantly harder.
If I would agree with the upstream's enforcement action, then they can ask me to sign onto it at the time it actually happens. If I would not agree, then I see no reason to give them permission in advance. Regardless, they have the legal right to use the code. From my perspective, their personal preferences regarding how a purely hypothetical enforcement action would proceed are not my problem.
> Give me a break. Here's a related link.
Your link does not appear to be relevant to my argument, but instead merely states a preference to avoid the use of a specific term because it carries certain connotations, connotations which my argument does not depend on and which are entirely unrelated to this discussion. Since it is not relevant, I am ignoring it entirely. Posted Sep 26, 2020 0:00 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (14 responses)
> And there is a barrier to pulling your code: enforcing copyright when you don't own the copyright is significantly harder.
The Linux kernel seems fairly successful in that. And the structure of Emacs should aid in that; whether or not a Lisp package is owned by the FSF should be irrelevant if they infringed on Emacs, a complete tool without that Lisp package. It wouldn't give them control if that Lisp package was infringed alone, but that's life, and I would think that's pretty far down the list of things the FSF should be worrying about.
Posted Sep 26, 2020 1:53 UTC (Sat)
by pizza (subscriber, #46)
[Link] (13 responses)
Huh? If anything, the Linux kernel is a poster child for _poor_ copyright enforcement, because nearly everyone in a position to actually enforce it has deliberately (and publicly) chosen not to.
And even when they want to enforce their rights, the sheer size of Linux versus any one individual contributor's portion makes it considerably harder -- this is a large part of why the VMWare suit failed.
Posted Sep 26, 2020 18:54 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
This is a Good Thing. It means the Linux kernel developers are exercising personal agency over their code, rather than blindly allowing people who have contributed nothing to the kernel's development to make decisions on their behalf. It means that enforcement is more a matter of community norms and less a matter of "Here's what the FSF/SF[L]C/[somebody else who didn't write the kernel] says the GPL means."
I realize this frustrates Free Software activists to no end, but the desires of Free Software activists are not LKML's primary concern. Their goal has always been to have a kernel that (mostly) works and is (mostly) portable, and their licensing decisions have enabled them to accomplish that goal (by getting compatibility patches back, and mainlining them where it is appropriate and practical to do so). It is not reasonable to declare their process a failure when it is working exactly as they intended.
"Surely they cannot have intended widespread violations of the GPL?" you might ask. That's the wrong question. If they're unwilling to enforce, that means they don't think it's a violation in the first place, or at least not a violation that they actually care about. You may disagree on either or both of those points, but it's up to them to decide how and when they enforce their copyright.
> And even when they want to enforce their rights, the sheer size of Linux versus any one individual contributor's portion makes it considerably harder -- this is a large part of why the VMWare suit failed.
This is potentially a more serious problem - but it ultimately comes down to the same community norms. If you go around trying to recruit individual developers for a lawsuit, you are probably going to face issues getting a critical mass of people to sign up. You need to reach out to the community as a whole and convince them that the lawsuit is in the best interest of the project, and then you should be able to come up with enough plaintiffs with (between them) enough code contributions to demonstrate infringement.
That's rough when the project doesn't care about Free Software values. Too bad, it's not your code. You don't get to tell them how to enforce their copyrights. If most of them didn't want to sue VMWare, then maybe suing VMWare wasn't in the interest of the project after all. Or maybe it was, but the SFC did a bad job of reaching out to the community; I haven't adequately investigated this specific case to say what happened there. I will note that the SFC's FAQ conspicuously fails to mention any direct and explicit outreach to LKML for additional plaintiffs, but perhaps they didn't even realize it would be necessary or useful to do so, or perhaps they did reach out, but felt it would be unnecessary to record such a discussion in their FAQ. Hopefully, going forward, such outreach will be standard practice when dealing with GPL violations involving the kernel.
Posted Sep 26, 2020 19:29 UTC (Sat)
by pizza (subscriber, #46)
[Link] (2 responses)
As the copyright holder for a couple of (mostly obsolete) chunks of the Linux kernel, I strongly disagree.
> I realize this frustrates Free Software activists to no end
Who gives a crap about what nebulous "free software activists" want? I, as an *end user*, want the complete corresponding source code I was promised. That's it.
Posted Sep 27, 2020 6:20 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
This is a gross misunderstanding of the GPL, and of copyright law generally. No promise was ever made to any end users, so there is nothing for them to demand in the first place.
Rather, a promise was made to the original copyright holders. While the GPL may have been intended to give rights to end users, that is not what it actually does, nor is it what Linus (at least) wanted out of the GPL anyway (see https://www.youtube.com/watch?v=PaKIZ7gJlRU). And this is fine. People can use the same license to very different ends. This is cold comfort when you're the end user trying to get the source that you just *know* the XYZ company is required to provide, and nobody on LKML cares, but it's their code. If they want to let people steal it, that's their choice. Perhaps it is an unwise choice, but a choice nonetheless.
> As the copyright holder for a couple of (mostly obsolete) chunks of the Linux kernel, I strongly disagree.
If you can find people infringing on those specific chunks, you are free to do as you see fit, in your role as the copyright holder for those chunks. But not in your role as an end user, because end users are not parties to the GPL.
Posted Sep 27, 2020 7:57 UTC (Sun)
by dvdeug (guest, #10998)
[Link]
So, yeah, if you want what the GPL was intended to give you, it doesn't seem a gross misunderstanding of the GPL to expect that.
> No promise was ever made to any end users, so there is nothing for them to demand in the first place. ... People can use the same license to very different ends.
It seems you're making RMS's case for him. Above you say:
> You have the code, it is fully GPL-compliant, and (as a result) it's already licensed under the same terms as upstream.
But then you say that functionally it's licensed under very different terms, that functionally an end user has no right to expect creators of a derivative work to offer source code for the work. RMS wants Emacs, and by Emacs I mean the whole thing the FSF distributes in one tarball, to be free software with end users provided with source code for derivative works.
My problem with such a treatment of licenses is a free content provider; as an uploader of photographs to Commons, every time someone slaps the CC-BY-SA on their photo and then lets people use it as if it were public domain, it reduces the value of my CC-BY-SA on my photograph. If everyone is treating CC-BY-SA as being public domain, then I'm being unreasonable when I demand the works be treated as per the license. If one or two copyright owners of GPLed works get tetchy about distribution of their code against the licence, the rest of us are likely to be treated as unreasonable nuisances when complaining about license-infringing distribution; if many copyright holders so act, then normal (not pirates, not carefully conscientious) distributors will make an effort to follow the license.
Posted Sep 26, 2020 20:40 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
Posted Sep 27, 2020 6:33 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Is Canonical a "bad actor" within your definition?
Posted Sep 27, 2020 6:38 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
A couple of jobs before, we had a NAS appliance that ran a copy of Linux with special RAID drivers and device management drivers (cooling, temperature sensors). Without any source code provided. This is another example of a bad vendor.
Posted Sep 27, 2020 18:29 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (5 responses)
Just like they have with a permissive license.
I think the tl;dr is "The kernel uses the GPL in a more permissive way". Nowhere near as permissive as a BSD license of course but more permissive than Emacs and other FSF software. I can understand the frustration of the "real" copyleft fans seeing their (world-domination...) tool used in a weaker way than intended.
Posted Sep 27, 2020 19:05 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
GPL has very real compliance costs that a good actor has to pay. This will increase the price of the product and/or make it more complicated (for example, you might have to move your "secret sauce" from kernelspace to userspace). A bad actor can just ignore these costs.
With permissive licenses the compliance cost is usually trivial. So all vendors are on the level playing field.
Posted Sep 28, 2020 10:04 UTC (Mon)
by ibukanov (subscriber, #3942)
[Link] (3 responses)
And again, the license alone just sets an upper bounds on efforts to comply. The real required efforts depends on copyright holders. And in case of Linux those effectively decided that it is better to have Linux on more devices even if the collateral is that in a lot cases the device manufactures do not follow GPL.
Posted Sep 28, 2020 16:17 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Good and bad can be subjective but I think you're stretching that a bit too far. I doubt violating software licences for profit is considered "good" in any culture. I'm sure it's "not as bad" in some or can yield precedence to some higher cause in others but "good"?
Now of course most consumers will have no idea that their device violates the GPL but that's ignorance not subjectivity.
Posted Sep 28, 2020 16:38 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 28, 2020 19:17 UTC (Mon)
by dvdeug (guest, #10998)
[Link]
In the case of Linux, like any other work with so many copyright holders, it's clear that at least some copyright holders don't agree with this implicit license, even if they don't always have the will to go through with a court battle. That's why we have explicit licenses, so all the copyright holders on Linux can get together and agree on the terms.
Posted Sep 25, 2020 23:55 UTC (Fri)
by sdalley (subscriber, #18550)
[Link]
This seems a really quaint limitation in this day and age. But who knows, maybe version 28 will succeed in fixing even this.
It might even succeed in dragging it kicking and screaming into the 1990's, when the CUA90 shortcut key standards (copy=ctrl-C etc) were introduced.
Posted Sep 26, 2020 0:51 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Sep 26, 2020 8:32 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (5 responses)
* Yeah, yeah, concerns about the power of Google. At the end of the day, I don't think many people want to ssh into one computer to read their email or newsgroups over a text interface; either they have one system that does it with a GUI, or they use their web browser.
Posted Sep 26, 2020 10:38 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (4 responses)
Emacs is a power tool. Like all power tools it has a steep learning curve. To quote my brother from god knows how many years ago - when he started using emacs he didn't know what all the fuss was about, fast forward a few years and as a power user he wouldn't be without it.
Sounds like you're not using it enough to appreciate it.
Oh - and the value proposition from guis is WAY over-rated. I still miss the Sheffield Editor - probably very similar to vim but it was basically a combination of Pr1me ed (itself probably pretty much the original ed), and a screen editor for terminals. Small changes you use the screen editor but I was forever dropping into ed mode and running commands over the entire file - try that with a gui!!!
I've got the source for the Sheffield Editor, but it's written in Pr1me Pascal so firstly I'd have to convert it to standard Pascal, and then find a compiler, and then get it to work with modern terminals :-)
Cheers,
Posted Sep 26, 2020 22:32 UTC (Sat)
by gus3 (guest, #61103)
[Link] (1 responses)
Posted Sep 27, 2020 8:31 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
I then got given a copy some years later. I guess if someone emailed the Sheffield University Computer Department they would probably give us a disclaimer.
If you want it, I'll have to hunt it down - it's on my computer somewhere - and I'll email it you. If you haven't got my email you'll find it on my user page on the linux raid wiki - drop me a line.
Cheers,
Posted Sep 27, 2020 23:20 UTC (Sun)
by jwarnica (subscriber, #27492)
[Link] (1 responses)
Such crazy.
I was more or less, out of obligation of corporate windows desktop, Linux systems, and local culture to adopt VSCode as an editor on a gig last year.
It's mostly consistent with standards put on the world by the IBM PC standard. And because of that, and a bunch of actually existing plugins, I was as productive with it, in a few days, as I've ever been in any IDE. I'll grant I don't spend 40 hours a week refactoring code (data!), but I don't know who does.
I'll go as far as saying I did not learn VSCode at all. Because it just worked with they way one who uses computers would expect it to work.
Posted Sep 28, 2020 6:59 UTC (Mon)
by madscientist (subscriber, #16861)
[Link]
Well, maybe I've just been using computers for TOO long and that's my problem. On the other hand my son also did some programming this summer and he also used vscode. He also had trouble getting various things to work (this was a large pre-existing C++ codebase, using a debugger, etc.) We spent a non-trivial amount of time searching the internet for the correct incantation of inscrutable JSON settings to add to various config files.
Yes, vscode is a good editor. It has some nice things. It does some things well. It also has some annoying things, and some things it doesn't do very well. If what you need to do is complex, then you will have to learn some new things, even with vscode. That's just a fact.
I get that some people are upset about the C-c/C-x thing. I agree, it's too bad that this conflict happened. But, "just change Emacs" is really a non-starter. C-c and C-x are two of the most fundamental keys in the entirety of Emacs. You can't just change those keys to something else! Well, I mean, of course you CAN just change them: it's Emacs after all. But no Emacs user who's been using the editor for more than a few weeks would be happy about that change. It's like telling a vi user that you are changing the colon key to mean something else.
The idea that resistance to the CUA change is simply RMS being an unreasonable autocrat is ludicrous.
Sure, have a mode that can enable CUA bindings (exists already, of course). Great. Maybe it could even be the default (on the assumption that experienced users will have an easier time resetting it than novice users will have setting it); I actually don't really care what the defaults are. But, the people who really KNOW Emacs, and the people who are DOCUMENTING Emacs, writing all the howto's, guides, wiki pages, providing help on StackOverflow, etc. etc. will all be using the traditional bindings. And probably 85% of solutions or improvements will involve using C-c or C-x at least once. Confusion will reign.
So it seems likely to me that anyone who wants to actually use Emacs as their editor that they program in all day every day will switch over to use the traditional bindings at some point anyway. Probably sooner rather than later.
Posted Sep 26, 2020 14:29 UTC (Sat)
by abo (subscriber, #77288)
[Link]
Posted Sep 26, 2020 15:33 UTC (Sat)
by shemminger (subscriber, #5739)
[Link] (24 responses)
Last time I tried all the others were either pay to play or poorly supported
Posted Sep 26, 2020 20:33 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (23 responses)
Posted Sep 27, 2020 1:20 UTC (Sun)
by loox (guest, #142138)
[Link] (9 responses)
1) I’m European. We live with accents and other exotic characters. More, being 2020, I use emoticons. Emacs _as is_ doesn’t work with Unicode. Please, don’t tell me how easy it is to fix it. Just fix it for me, thanks. Any other, er, modern editor is Unicode-enabled, period.
The chatting about dark mode or video tutorials is moot. It would be more useful, in fact, a graphical app with a micro-emacs inside, that people can try to discover the capabilities of emacs while getting work done in the while.
Thanks for the attention.
Posted Sep 27, 2020 12:24 UTC (Sun)
by khim (subscriber, #9252)
[Link] (6 responses)
Users are just a means to get more developers and developers are needed to make free software. If the price of getting more users is making software not free... then the whole point of attracting them is lost. P.S. Please don't tell me that it's absurd to put the needs/wants of the users lower then the needs/wants of some piece of software (software is not alive, it doesn't have needs, after all). I know that and kind of agree with that. But situation is different from FSF's POV: that's the organization which is specifically made to promote free software and not to make popular software which makes users happy.
Posted Sep 27, 2020 21:27 UTC (Sun)
by loox (guest, #142138)
[Link] (5 responses)
Excluding one and half billion machines from running GPLed software, in order to promote free software, is not smart. Are you telling me that Firefox isn't free software? What about vim? VLC? I can run these apps, as well as plenty of other free software, on iPad. Find common ground with Apple; create it if needed; solve the issue. The current standoff is not promoting free software; it is making emacs increasingly irrelevant. Excellent work, FSF. My compliments.
Posted Sep 27, 2020 22:46 UTC (Sun)
by pizza (subscriber, #46)
[Link]
Wow, next you'll tell us you have a plan for peace in the Middle East.
(I'm reminded of the saying "Democracy is two wolves and a sheep deciding what to have for dinner.")
Posted Sep 27, 2020 22:55 UTC (Sun)
by madscientist (subscriber, #16861)
[Link]
So why has no one else done it? I don't know. Maybe you do?
I have heard three different things: one is that Apple doesn't allow interpreters in programs that run on the iPad. If that's true, the entire basis of Emacs (which is a Lisp enterpreter) is not allowed. How do you suggest that this be worked around? Other people say this is not true, or it was true but is not true anymore, and that other examples of interpreters exist. So maybe that's not the problem.
I've also heard that Apple won't allow an application to download other software. If that's true, it means that you can't use Emacs' package facility to install extra elisp packages. If all you care about is vanilla Emacs I guess that's fine but most people use at least one add-on package. Perhaps whomever created Emacs for the iPad could add in a bunch of the most popular external elisp packages--but the odds that it will include everything you might want are slim. But still, someone could publish Emacs if this were the only issue.
I've also heard that Apple won't allow any program licensed under the GPLv3 to appear in the app store. If this is true, then this certainly would be something that could not be solved by a user who wanted to publish an iPad version of Emacs. If this is the problem, how do you suppose this should be worked around?
When you say "work it out", is it your belief that Apple will agree to some compromise where both parties give some ground to come to a resolution? If that's how you think it would work I recommend you read about the current situation between Epic Games and Apple.
What you're really saying is, the GNU project should give in completely to Apple and do whatever they want, in order to increase their user base to include a group of people who either don't know or don't care about the fundamental reason the FSF and the GNU project exists, or anyway don't care enough to avoid buying hardware that is completely anathema to that reason.
That MIGHT make sense if the goal of the GNU project was to get as many users as possible. Although, the aforementioned Epic Games shows that even if that is your goal you might not be able to come to terms with Apple.
However, the GNU project isn't about increasing market share, it's about increasing software freedom. Compromising their principles to gain a group of users who are happy buying hardware that will only work with pre-compiled software that is selected for them by a single company who exercises absolute control over anything they could run on that hardware is... not an attractive deal for them, to say the least.
Posted Sep 28, 2020 8:29 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Think Clang vs GCC. Currently Clang is ahead… but just barely — and that's when it's about 10x (if not 100x) more popular among developers of derived products. Why? Because only Google pushes Clang itself. Everyone else are doing their own proprietary forks… and development effort spent on these, sooner or later, becomes a loss. I'm not 100% sure which side would win (is it better to attract lots of users and developer even if 90% of development would go to waste… or is it better to have fewer developers — but the ones who care?), but I can certainly see where FSF comes from.
Posted Oct 8, 2020 19:33 UTC (Thu)
by markjanes (guest, #58426)
[Link] (1 responses)
I was surprised to find out that Firefox is prevented from running add-ons when running on iOS. For example, you cannot install adblock or extensions to ensure your browsing privacy.
https://support.mozilla.org/en-US/kb/add-ons-firefox-ios
Firefox as implemented on iOS is not free, because I am not free to run it in the manner that I choose.
Posted Oct 9, 2020 13:51 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 27, 2020 13:45 UTC (Sun)
by jem (subscriber, #24231)
[Link] (1 responses)
What problem do you have with accents in Emacs? I have not had any problems with them in Emacs for a long time. No configuration needed, either.
Emacs also supports emojis, I just tried and got a grinning face *in color* on screen in Emacs. Granted, I had to choose a font that supports emojis, and I had to enter it using "C-x 8 RET grinning face RET". How do you do that in your "modern, Unicode-enabled" editor? Is your keyboard equipped with a key that has a yellow grinning face printed on it?
Posted Sep 27, 2020 21:03 UTC (Sun)
by loox (guest, #142138)
[Link]
You're right; I stand corrected on this. Thanks!
Posted Sep 27, 2020 6:11 UTC (Sun)
by jem (subscriber, #24231)
[Link] (1 responses)
Now, as an IDE for, say, working on a Java project VSCode is far superior to Emacs. Install the Java Extension Pack with a few clicks and you have Java syntax highlighting and checking, completion and automatic imports. Not only that, you get support for building the project within VSCode, and an integrated debugger out of the box. For these reasons, I use VSCode instead of Emacs when working with Java, *but* with the Vim emulator extension to be able to use a real text editor.
By the way, I find it funny that, when talking about CUA (Common User Access), the examples given are the Ctrl-X, Ctrl-C and Ctrl-V key bindings. These key bindings are not in the CUA document, they were introduced by the Apple Macintosh as Command-{X,C,V}, and later ported to Windows as Ctrl-{X,C,V}. In CUA the Cut command is Shift+Del, Copy is Ctrl+Ins and Paste is Shift+Ins.
Posted Sep 27, 2020 6:16 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I honestly don't know what you want more from a pure text editor.
And yes, there's an IDE on top of VSCode if you need it (though I prefer IntelliJ products).
Posted Sep 27, 2020 10:13 UTC (Sun)
by pgdx (guest, #119243)
[Link] (10 responses)
Atom is good, vscode is good.
You cannot linearly order editors (that much should be clear by now). I can come up with many tasks that I can do much faster, easier, and more comfortably in Emacs than you can do in either of your editors.
Here's a thing I did the other day that was quite easy in Emacs: open a CSV file, sort by second column, make into a latex table and generate a nicely typeset pdf. Bonus points if you can inspect that very pdf in your editor. But that's just Emacs showing off, I guess...
Posted Sep 27, 2020 12:35 UTC (Sun)
by khim (subscriber, #9252)
[Link] (9 responses)
And if the answer is no, you can't, you need all the 600 pages of manual first… then that is where you have lost 90% of users. Now you are fighting for the remaining 10%… with VIM. So before Emacs would decide what to do… it's developers have to decide if they want to try to pull more of that 10% users or they are audacious enough to fight for the remaining 90%. Strategy would depend on that…
Posted Sep 27, 2020 14:18 UTC (Sun)
by pgdx (guest, #119243)
[Link] (8 responses)
Open csv file in csv-mode, run C-c C-s (for alphabetic sort) or C-c C-n
Now, enter org-mode, select the table and run C-c |. (Sounds weird, but
Finally, run C-c C-e l p (again, possibly weird, but C-c C-e is
Posted Sep 28, 2020 9:24 UTC (Mon)
by beagnach (guest, #32987)
[Link] (1 responses)
Posted Sep 28, 2020 10:30 UTC (Mon)
by pgdx (guest, #119243)
[Link]
No, that's not the point. It's certainly a point,
but it's not my point. My point was that the statement
Posted Sep 28, 2020 23:26 UTC (Mon)
by gus3 (guest, #61103)
[Link] (5 responses)
How to do that?
> Now, enter org-mode
Again, how to do that?
You're trying to explain how to do all this without reading 600 manual pages, right? If you're going to explain how to do something, make sure your entire audience (not just your expected audience) can get a clue, a feel for the task.
I'm writing this solely as someone with a glancing familiarity with Emacs.
Posted Sep 29, 2020 7:10 UTC (Tue)
by pgdx (guest, #119243)
[Link]
M-x csv-mode (it defaults to that if you open a CSV file, though, so probably unnecessary).
>> Now, enter org-mode
M-x org-mode.
If you're not familiar with M-x, it is (usually) Alt-x and then you type in your command, e.g. help, apropos, whitespace-cleanup, org-mode, markdown-mode, csv-sort-fields, sort-lines, magit-blame, etc.... The set of available commands depends on your "current mode" (e.g. java, csv, org, markdown, text, mail, ...).
Posted Sep 29, 2020 7:41 UTC (Tue)
by jem (subscriber, #24231)
[Link] (3 responses)
This is getting ridiculous. The task at hand obviously is not easily solvable by a "complete novice" of any tool, unless the tool is specifically coded for the task. It is definitely not solvable by the praised Emacs competitors like Atom and VS Code, without coding an extension in Typescript or some such. In Emacs the needed pieces are readily available, and if you don't feel like reading the manual you may be able to find someone who can whip up a semi-friendly front end that makes use of the existing Emacs csv-mode and org-mode packages. You don't need to read 600 pages of manual to start using Emacs. You can start using it just like Windows Notepad (or a Notepad-like editor like VS Code): open a file by choosing Open File... in the File menu. Move around in the text using the arrow keys (or Ctrl-arrow for moving by word), the Page Up and Page Down keys, Home, End, Ctrl-Home, Ctrl-End. Edit the text using the Backspace and Delete keys; again, you can combine these keys with Ctrl to delete by word. Click on and select text using the mouse, if that's the way you want to work. Unfortunately, for historical reasons, a few common Ctrl key combinations are different, so you will have to learn the Emacs alternatives for cut, copy, paste and undo (which, by the way, are also available for selection in the Edit menu). Oh well, I guess that's too much for the typical attention span of people today... One more thing: the Real CUA key combinations for cut (Shift-Del), copy (Ctrl-Ins) and paste (Shift-Ins) are also available. Apple forced us to learn new key combinations for those functions.
Posted Sep 29, 2020 9:00 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
When you open a file in Emacs you get a full screen of it. There are no tabs and navigation between open files (who said "buffers"?) is NOT trivial. And it's a completely different model from everything else.
So basically you HAVE to start with reading the manual and un-learning all the muscle memory. CUA mode doesn't particularly help. As far as I remember, even text selection worked differently (not the usual shift+movement keys).
Posted Sep 30, 2020 2:20 UTC (Wed)
by dvdeug (guest, #10998)
[Link] (1 responses)
> One more thing: the Real CUA key combinations for cut (Shift-Del), copy (Ctrl-Ins) and paste (Shift-Ins) are also available. Apple forced us to learn new key combinations for those functions.
Because the original ones were horrible? Maybe if any two keyboards kept Del and Ins in the same spot, I could learn to touch-type with them, but that would still require moving my right hand from the normal position.
Posted Sep 30, 2020 6:26 UTC (Wed)
by jem (subscriber, #24231)
[Link]
I really doubt a complete novice (not my words) could do it with Excel either. But the general expectation seems to be that if you are unable to do something in Excel, then "stop complaining and start learning". My objection was directed at commenter pgdx who complained that if a "complete novice" can't do this convoluted task without reading 600 pages of manual then "then that is where you have lost 90% of users." Isn't it a bit unfair to expect Emacs to enable someone who has always lived under a rock to be able to handle CSV files using it, without first learning the basics?
Another joke is that Emacs stands for "Eight Megabytes And Constantly Swapping". Oh, the horror.
>Why should I open a CSV file in a text editor and expect it to be treated like a spreadsheet?
You don't have to, if you don't want to. I guess the example was just to demonstrate how powerful and extendible Emacs is. If you don't care about org-mode or csv-mode, then please ignore them. They don't bloat Emacs, other than taking up a bit of disk space.
>Because the original ones were horrible? Maybe if any two keyboards kept Del and Ins in the same spot, I could learn to touch-type with them, but that would still require moving my right hand from the normal position.
My comment on the CUA key bindings was written with tongue in cheek. My point was that key bindings have not been set in stone since the beginning of the IT era, and also that talking about Ctrl-x/c/v as "Common User Access Keys" is a misnomer.
Posted Sep 27, 2020 16:29 UTC (Sun)
by ard (guest, #139727)
[Link] (18 responses)
I have been using Emacs for 10 years and it works well for me - I use Elpy for Python, go-mode for Go, cc-mode with company-mode and smart-compile for C, Magit for Git integration, yasnippets. All of the features you'd expect from contemporary IDEs are here - auto complete, on the fly syntax checking, integrated debugger, refactoring capabilities, showing documentation for symbol at point, narrowing, jumping to definition. It's hard to come across file written in a programming language for which Emacs wouldn't at least provide syntax coloring out of the box - I've just tried .java, .kt, various assembly types.
I've also used Jira mode that allowed me to list all tasks assigned to me, comment on them and create new tasks without leaving Emacs. Additionally, I can use Emacs without touching a mouse and in server-client mode so I have access to all existing buffers when writing an e-mail in Mutt or when using sudoedit. I use zenburn theme because I prefer darker colors.
A couple of things I looked into recently: JSON mode - it's here https://github.com/joshwnj/json-mode, Rust mode - it's here https://github.com/rust-lang/rust-mode.
If you cannot figure out how to use a mailing list feel free to ask questions on Emacs SE: https://emacs.stackexchange.com.
Nothing is perfect though - one of the things I don't like about Emacs is that it cannot be run under Wayland without using XWayland because 'it is not a proper gtk application' or whatever https://emacshorrors.com/posts/psa-emacs-is-not-a-proper-....
Posted Sep 27, 2020 18:41 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (17 responses)
Been living under a rock?
I try to avoid the word "modern" when possible but it's getting difficult when the developers relying on email the most use the words "stone tablets".
Posted Sep 27, 2020 18:52 UTC (Sun)
by ard (guest, #139727)
[Link] (16 responses)
Posted Sep 27, 2020 20:09 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (15 responses)
Non idea how you got that. I quoted a very specific sentence from you.
Posted Sep 27, 2020 20:13 UTC (Sun)
by ard (guest, #139727)
[Link] (14 responses)
Posted Sep 28, 2020 2:27 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (13 responses)
Posted Sep 28, 2020 4:26 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
Posted Sep 28, 2020 8:36 UTC (Mon)
by ard (guest, #139727)
[Link] (11 responses)
And? There is also a whole generation of developers who have never used C or command line but you cannot say that these things are not used any more. Everyone uses e-mail though, using mailing list is easy especially if you do not need to subscribe. If you don't know how to use a mailing list you will never contribute to Linux or Freebsd kernels or projects such as busybox, U-boot and others. Newer projects such as https://core.dpdk.org/contribute (started in 2012) that I got interested in lately also use mailing lists. So it's not about whether someone has used it or not - they can always give it a try, someday they might have to if they'll want to contribute and there's nothing wrong with that - this is called learning.
Posted Sep 28, 2020 18:26 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (10 responses)
Good thing no one said that then but please keep arguing with yourself again.
> this is called learning.
I've already used mailing-lists and I'm still using some sometimes. That's why I try to avoid them.
> Everyone uses e-mail though, using mailing list is easy especially if you do not need to subscribe
If you're interested in learning this assumption has already been questioned and discussed a million times on this site - and others.
Random example: https://lwn.net/Articles/817668/
By the way it's not mailing-lists that seem to be losing steam; email as a whole too. "Blame" Facebook, Whatsapp and what not.
> If you don't know how to use a mailing list you will never contribute to Linux or Freebsd kernels or projects such as busybox, U-boot and others.
Exactly one of the top issues that has already been discussed a million times, welcome to the party. Better late than never.
Posted Sep 28, 2020 18:51 UTC (Mon)
by ard (guest, #139727)
[Link] (9 responses)
It's either me or you should express your thoughts more clearly.
> > this is called learning.
You see, and I *prefer* using mailing lists over Web-based forums.
> > Everyone uses e-mail though, using mailing list is easy especially if you
Wow, if you didn't tell me that I wouldn't even know that
> By the way it's not mailing-lists that seem to be losing steam; email as a
I don't use e-mail on my phone when I want to ask someone if we hang
>
Well, if someone cannot figure out how to use e-mail they'd better not
Posted Sep 28, 2020 20:52 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (8 responses)
I clarified "this is not what I said". pabs gave a good example that I endorsed. Yet you kept at it. If you're not sure what I meant don't keep making me say what you fancy answering instead. This site is one of the few left where people try to understand each other in the comments section.
> It's still widely used in business because it's versatile, unified, independent and secure
I agree with most of your technical description of email here but it doesn't automatically follow that email should be used for everything including code reviews and project collaboration, no more than it implies email is good substitute for databases (which most "modern" tools rely on = not so random example).
> > This assumption has already been questioned and discussed a million times on this site - and others.
Yet I can't resist addressing this particular, knee-jerk justification:
> Well, if someone cannot figure out how to use e-mail they'd better not contribute.
s/figure out/like/
I know how to use email; I even knew how to send a message with telnet 25 and retrieve them on port 110 (before everything became encrypted). I just _prefer_ to avoid email when I can because I find it messy, disorganized and not productive.
I perform a number of code reviews daily and I can understand the temptation not to make too easy to contribute but seriously: use email because you think it's the best way for the project to communicate, not because there are technically easier ways to communicate!? That's the worst reason ever and possibly turning off people who like email but not this kind of attitude and to be honest it lowers the credit of other, much better points you made. Don't mix up two totally different problems.
For instance a much better way to filter contributors and save maintainer time is not to start reviewing anything until all tests and checks pass in CI (or have a very good, written justification why they don't). Now you know the wannabee contributor had the technical skills to perform something actually useful and relevant: reproduce and troubleshoot failures and fix them. If no CI failure (for instance because of lack of test coverage), asking for new tests is another much better litmus test.
This is just an example I bet you can find others. BTW any _single_ litmus test carries a "monoculture" risk.
In general creating an artificial shortage of contributors because there is a shortage of maintainers is playing with fire from a long term, natural selection perspective, so proceed very carefully. Even betting you'll be the next "COBOL generation" pulled out of retirement at great expense would be risky ;-) There are many open-source projects to contribute to, many more than ever before and there is a shortage of smart contributors too. So good luck finding your next generation maintainers if you purposely rely on a litmus test as bad as "Do you like email?"
Posted Sep 28, 2020 21:45 UTC (Mon)
by ard (guest, #139727)
[Link] (7 responses)
Everybody does. And I didn't mean that YOU don't know how to use
> I even knew how to send a message with telnet 25
Cool, I use telnet only for tests. I use Mutt + msmtp + offlineimap +
> I just _prefer_ to avoid email when I can because I find it messy,
And I find e-mail something completely opposite - organized (mutt has
> I perform a number of code reviews daily and I can understand the
As I explained, I find e-mail technically easy to use. I also find web
> That's the worst reason ever and possibly turning off people who
I don't get it.
> For instance a much better way to filter contributors and save maintainer
Yes, this is good.
> Now you know the wannabee contributor had the technical skills to
ok but what's your point here? Are you saying there is no CI on
> This is just an example I bet you can find others. BTW any _single_ litmus
But this is not 'artificial shortage of contributors', I don't know
> Even betting you'll be the next "COBOL generation" pulled out of
Don't worry about me, I have to work for another 35 years to achieve
> There are many open-source projects to contribute to
I know, I contributed to many.
> many more than ever before
There are many although their quality and usefulness vary.
> and there is a shortage of smart contributors too.
Smart contributors - yes, smart.
> So good luck finding your next generation maintainers if you
I don't do that.
Posted Sep 28, 2020 22:57 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (6 responses)
> Everybody does. And I didn't mean that YOU don't know how to use e-mail - I meant that if someone wants to contribute to a project that uses e-mail they should be intellectually able to figure out how to use their e-mail client, git-send-mail and git-am.
This is not really about configuring an email client or using git. It's about organizing the information overload you're describing:
> And I find e-mail something completely opposite - organized (mutt has good searching capabilities: I can filter e-mails by From: or To: headers, by subject, by e-mail body; I can move e-mails to other mailboxes; can easily backup my ~/.muttmail even though all messages are also kept on the server;
I prefer not having to do most of these _at all_.
BTW referring to mutt in a discussion about ease of use is... interesting?
> As I explained, I find e-mail technically easy to use.
Great but this discussion isn't about you cause you already prefer email.
> I also find web forms technically use to use though slightly less convenient because I hate using mouse
You just hit the second most common misconception in this discussion. While the web is clearly the preferred database interface these days, there's no fundamental requirement for it to be. If some people manage to get something out of github from Emacs (github = the closed source poster child of open source), surely it's possible to do even better with alternatives to github.
> ok but what's your point here? Are you saying there is no CI on mailing lists?
Again, no idea how you got that. Information overload?
> they also have an interface that shows all patches sent, their state and shows the discussion https://lore.kernel.org/patchwork/project/lkml/list (I heard managers like it this way).
Exactly: this as close to "modern" as kernel development gets. Re-constructing a missing code review database from loose emails as opposed to having some sort of email (and other) interfaces from a code review database like everyone else does. A code review database means someone joining the project 2 years later and debugging a long standing issue can find all the relevant information and barely any irrelevant information in a jiffy. No email organization needed. Meanwhile: https://lwn.net/Articles/797613/
Also: https://damien.lespiau.name/posts/2016-02-13-augmenting-m...
> is github project A intentionally creating shortage of contributors this way?
Yes but not intentionally and (IMHO) not as much as with email. I mean I've never read this: "Well, if someone cannot figure out how to use github they'd better not contribute." In fact github's constant efforts are the exact opposite of that.
> > There are many open-source projects to contribute to
> I know, I contributed to many.
Just to be clear: I meant including many that do not require email.
> > So good luck finding your next generation maintainers if you
> I don't do that.
I'm pretty sure you just did.
Also sure you still have a lot of past discussions to catch up with. Write less and read more (and more slowly).
Posted Sep 28, 2020 23:33 UTC (Mon)
by ard (guest, #139727)
[Link] (5 responses)
> > > I know how to use email;
Information overload? E-mail contains From:, To:, Subject: and
> > And I find e-mail something completely opposite - organized (mutt has
You don't have to do that, you can. And what exactly would you prefer
> BTW referring to mutt in a discussion about ease of use is... interesting?
Sorry, "easy to use" might mean something completely different to
>
You asked me:
> I perform a number of code reviews daily and I can understand the
and so I answered.
> > I also find web forms technically use to use though slightly less
Surely it's also possible with e-mail. BTW, I have never wished to use
> > ok but what's your point here? Are you saying there is no CI on mailing
> Just to be clear: I meant including many that do not require email.
There are no projects that do not require e-mail because you have to
> > > So good luck finding your next generation maintainers if you
No. Use the right tool for the job. If you want to contribute, follow
> Also sure you still have a lot of past discussions to catch up with. Write
Honestly, I have a very hard time trying to understand your
Posted Sep 29, 2020 15:30 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (4 responses)
I shared a number of references but it doesn't seem you tried to read any other post. You're only interested in explaining how perfect email is (for you).
Posted Sep 29, 2020 17:18 UTC (Tue)
by pizza (subscriber, #46)
[Link] (3 responses)
I should point out here that his comfort with email is fine, just as the email-centric development model of emacs (or whatever) is also fine -- it serves those doing the work quite well. Indeed, hyper-customizable tooling is the entire raison d'etre of emacs, and non-email server-based workflows invariably require using someone else's tooling.
If someone wishes those folks to change a development model/methodology they personally find very productive (and aligns with their overall principles) for something significantly different, that someone will have to show how those changes will be an overall improvement _for the existing team_ -- they are, after all, the ones who are doing the work, and are all volunteers.
Anyway.
Posted Sep 29, 2020 17:37 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Totally agreed - as long the existing team doesn't "live under a rock", doesn't place non-technical objectives too far above technical ones and can generally listen to unusual perspectives. Otherwise it would just be a lost cause it would be better to either fork or look for alternatives and not just for tooling reasons.
Another option when you can afford it and when the size of the project justifies it is to "fragment and bridge" the tooling, this is what happens for the kernel for instance.
> and are all volunteers.
Depends on the project.
Posted Sep 29, 2020 17:56 UTC (Tue)
by ard (guest, #139727)
[Link]
But who does that? I'm not a member of Emacs core team and never sent
> Otherwise it would just be a lost cause it would be better to either
Emacs has been forked multiple times, and it will be forked multiple
> Another option when you can afford it and when the size of the project
Emacs is, however, a much smaller project compared to kernel
Posted Sep 29, 2020 18:25 UTC (Tue)
by pizza (subscriber, #46)
[Link]
Well, yes -- the developers doing the actual work are the ones who ultimately decide what direction a project takes, up to and including forking it if the nominal "owners" are intransigent.
If RMS is truly the only impediment to "progress" in emacs, then its most productive developers will revolt and fork it. It won't even be the first time this has happened to a core GNU package.
Posted Sep 27, 2020 17:30 UTC (Sun)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Oct 4, 2020 11:58 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link]
Posted Sep 27, 2020 20:44 UTC (Sun)
by wjb (subscriber, #71810)
[Link]
Posted Oct 1, 2020 19:20 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
https://spacemacs.org is how I use Emacs.
What the community might consider is how to better integrate and expose sets of functionality along the lines of spacemacs.
Posted Oct 3, 2020 14:15 UTC (Sat)
by cgwaldman (subscriber, #9061)
[Link] (1 responses)
Posted Oct 3, 2020 21:45 UTC (Sat)
by thumperward (guest, #34368)
[Link]
There is an incredible irony in that the man generally heralded as the founder of the movement for software collaboration is impossible to work with.
Posted Oct 4, 2020 11:53 UTC (Sun)
by wtarreau (subscriber, #51152)
[Link] (1 responses)
There's no incentive for developers to actually *learn* how to master it since it will be worthless again 1 year later.
On the input side, I'm still very annoyed by the stubbornness in confusing tabs and spaces. Tabs are for indent, spaces for alignment, but I somewhat gave up and finally spend my time deleting wrong tabs and replacing them with spaces by hand. Having lost the ability to delete a region without copying it into the buffer when switching from Xemacs to emacs continues to annoy me as well, because I cannot easily use the same block to replace many occurrences of a seemingly identical block anymore.
Still it's the editor I find myself most comfortable with. But I also hate it for its strong refusal to adapt to my needs nor helping me perform rare operations. Very often I find myself saving my file an running sed or vi on it for a repetitive operation that would take hours to figure inside emacs. Contrary to its original author I don't live in ideology nor dogma and just want to get things done efficiently, so if I can do something easier with something else, I switch for the time it takes to do it.
The first thing to think about for future versions, instead of switching colors, is to think about *keeping* users by giving them less incentive to use other tools in the first place, even temporarily. There are extremely few emacs users around me, all others seem to be on gvim an to be mostly happy. Thinking that it's probably much easier to switch from emacs to gvim than the other way around suggests that not tempting to switch (even just for a small operation) is the most important thing to achieve.
Posted Oct 4, 2020 21:15 UTC (Sun)
by jhhaller (guest, #56103)
[Link]
Posted Oct 17, 2020 14:14 UTC (Sat)
by seagle0128 (guest, #142585)
[Link]
Take a page from "Portlandia" -- put a bird on it -- and leave it at that.
Toward a "modern" Emacs
Toward a "modern" Emacs
This points to one idea that did not really come up in the discussion, but which should be considered: part of the key to making Emacs more attractive to users might be making its development community more attractive to contributors. Adopting some of the more forge-oriented tools favored by younger developers might help in this regard, as might a less centralized governance model. Emacs remains an old-style GNU project, a fact which clearly grates on its developers at times. Increasing the relevance of Emacs in the coming years is going to require more than new key bindings and some cat videos; it is likely to require attention to improving the experience at all levels.
```
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
Wol
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
RMS's definition of "free software" is clear enough, and non-copyleft licences like BSD/MIT/Apache entirely qualify.
copyleft software, not "free" software
“Free software” means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”. We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.
Various comments on copyleft and non-copyleft licences are here. Note that objections to individual non-copyleft licences are not for their permissiveness but to unclear names (what does "BSD licence" or "MIT licence" mean?) or GPL incompatibility (eg the BSD licence with advertising clause; CDDL; APSL). The Apache 2.0 licence is strongly recommended as a permissive free software licence.
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
copyleft software, not "free" software
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
>> "It is unfortunate that the people who implemented the newer editors chose incompatibility with Emacs."
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
https://archive.fosdem.org/2020/schedule/event/open_sourc...
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Please give doom-emacs a try.
Includes evil-mode, easy configuration and fast startup times though featuring everything that makes Emacs great like magit.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
There are currently over 200 people with commit rights.
For the curious, I did a quick gitdm run; from 26.1 to 27.1 saw 8237 patches from 326 developers. 50% of those came from five developers (Lars Ingebrigtsen, Eli Zaretskii, Paul Eggert, Michael Albinus, Stefan Monnier). There are 166 people who contributed exactly one patch toward this release.
Developers
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
requests and patches/implementations should be sent to
bug-gnu-emacs@gnu.org" and then it has instructions on how to send a
patch. There is nothing about needing to subscribe to do it.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
$ xrdb -n -query | grep -i emacs
Emacs.background: Black
Emacs.bold.attributeForeground: Blue
Emacs.foreground: Wheat1
Emacs.italic.attributeForeground: hotpink
Toward a "modern" Emacs
That would give me white on black. I want wheat1 on black. ☺️
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
I've never found this to be a problem in practice. When you're first navigating a large new software project, you don't change it much and etags is indispensable for navigating it. After that, refreshing a couple of times a day is generally good enough.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
It's a "technically inferior" solution whose inferiority matters roughly 0.00% of the time, to the nearest hundredth of a percent. This is really nitpicking.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
I also investigated using VSCode for Perl development. The Perl extension I found asks you to install (surprise) ctags. So again, meh.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
This editor has easy access to "git grep", so I click on a name, "Alt-dot", and up pops a list of matches, which I can select from or walk through. Sometimes finding the declaration among all the uses is tricky, but usually it is no trouble.
The result of "git grep" is always completely up-to-date!
Toward a "modern" Emacs
Indexing matters, if your full data set doesn't fit in RAM.
These days we have Google search, which is faster than finding something on your local machine.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
https://www.gnu.org/philosophy/words-to-avoid.en.html#Sof...
Toward a "modern" Emacs
Toward a "modern" Emacs
My understanding was that you do not get back the copyright, that you are instead granted a non-exclusive license to do what you want with your contribution. That is an important distinction: it determines who can take legal action against infringers, that was one of the reasons for having the copyright assignment in the first place. I looked for examples of the copyright assignment papers and found Free Software Foundation Copyright Assignment Form, which supports my understanding. Have things changed since then?
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
> The Linux kernel seems fairly successful in that.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
The lack of enforcement means that bad actors have competitive advantage over good actors.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
No, it's not.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Wol
Toward a "modern" Emacs
Toward a "modern" Emacs
Wol
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
‘Many forms of Text Editor on Linux have been tried, and will be tried in this world of sin and woe. No one pretends that Emacs is perfect or all-wise. Indeed it has been said that Emacs is the worst type of text editor except for all those other forms that have been tried from time to time.…’
Toward a "modern" Emacs
Toward a "modern" Emacs - First Steps
2) I’m in bed at the moment, writing with my iPad. Tomorrow morning I’ll wake up, I’ll wake my Mac up, and I’ll instantly work with whatever document I was working now on the iPad. This means:
2a) I want emacs on my iPad. I sorely miss BBEdit in my iPad. A reason to switch to emacs would be the ability to u se it from my iPad. I realize that having emacs on a iPhone borders with absurd; ok. Having it on the iPad doesn’t.
2b) Synchronization. Please make Emacs iCloud-ready, Dropbox-ready, Pcloud-ready, Box-ready, whatever-ready if you don’t want to create emacs’ own sync service.
I fully understand the conflicts between GPL and the App Store. Sorry, I’m not a lawyer; I’m a user. Want emacs to appeal more to users? Make it work for users, then. Write GPL4 if needed, talk with Apple and Google, kiss a frog. This crusade against app stores is not in the interest of users. If an app is universally available to whoever wants to download it, freedom of redistributing it is actually pointless. GPL should contemplate an exception in this case.
3) Import-Export. Make it easy to import and export common formats. I know you’re programmers; I’m more of an editor, Please make easy, really easy, to output a PDF, writing in Markdown, preview an HTML document.
Toward a "modern" Emacs - First Steps
Having it on the iPad doesn’t.
Of course it's absurd. Apple made it impossible to make GPLed programs for iPad and don't think FSF would be willing to compromise.
Please make Emacs iCloud-ready, Dropbox-ready, Pcloud-ready, Box-ready, whatever-ready if you don’t want to create emacs’ own sync service.
FSF would never do that and you know why.
I fully understand the conflicts between GPL and the App Store. Sorry, I’m not a lawyer; I’m a user.
If you say that then you don't understand the conflict.
Write GPL4 if needed, talk with Apple and Google, kiss a frog.
Lol. And what would be the end result? More users? But FSF's end goal is not to make users happy!
It would be more useful, in fact, a graphical app with a micro-emacs inside, that people can try to discover the capabilities of emacs while getting work done in the while.
How would that help to produce more free software? That the main goal here, remember?
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Are you telling me that Firefox isn't free software? What about vim? VLC?
As distributed on iPad/iPhone? All of these are not free. FSF even includes nice diagram to underscore it
I can run these apps, as well as plenty of other free software, on iPad.
No. You can't. All that software, as per FSF's definition is non-Free. And FSF argues that free software is better than open source. If you can run certain free software program then that means that their authors have given up on the free software and produced proprietary version for you to consume.
The current standoff is not promoting free software; it is making emacs increasingly irrelevant.
That's more-or-less what FSF heard about… well, few times per year for it's 35 years of existence. Their chances haven't changed. I don't think your rant would impress them all that much.Excellent work, FSF. My compliments.
I know have meant that to be sarcastic... but I actually applaud them. At one time I was sure “open source” won and “free software” lost… but today… I'm not so sure anymore.
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs - First Steps
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Here's a thing I did the other day that was quite easy in Emacs: open a CSV file, sort by second column, make into a latex table and generate a nicely typeset pdf. Bonus points if you can inspect that very pdf in your editor.
Wow. That's pretty cool. Maybe you can write an article which would explain how I, as complete novice who have never opened the manual and just wants to do that… can repeat that daring feat.But that's just Emacs showing off, I guess…
Not Emacs, but you, I suspect. Yes, Emacs can do that and more… but only for someone who knows how to program. Which is not the majority of users our there. And no, I'm not talking about the need to write actual lisp code. That can be avoided, I suspect. But the need to understand how programs work in principle… these are unavoidable. And majority of text editor users… have no idea about that.Toward a "modern" Emacs
achieve it. Also, you don't need to read 600 manual pages if you are
willing to just use a search engine.
(for numeric sort). If you haven't selected a region of the file
(typically the entire file or the entire file minus the header), Emacs
will select the entire file and ask you it you indeed want to sort the
entire file (including the first row). Then Emacs asks you which
column, and it defaults to the column your cursor is in (select 2).
pipe is column separator in org-mode, so it's quite natural if you're
familiar with org-mode.) If you want to make the first row the header
row, you simply press C-c -, which inserts a separator line under your
cursor.
org-export, and then l p means LaTeX and PDF).
Toward a "modern" Emacs
Toward a "modern" Emacs
Yes, it's simple, three steps, but the point is that a new user is never going to figure this out unaided.
Atom exists. VSCode exists. Both are superior editors to Emacs
isn't correct, at least not for me. I just tried to say that
there are things I'd rather do in Emacs than attempt to achieve in
either of the other two.
Toward a "modern" Emacs
Toward a "modern" Emacs
> How to do that?
> Again, how to do that?
Toward a "modern" Emacs
Toward a "modern" Emacs
I've actually tried this route back in 2006. And quickly discarded it. Back at that time I was already used to a "standard" layout: the project tree in the left and the tabbed editor on the right.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
>
> Good thing no one said that then but please keep arguing with yourself
> again.
>
> I've already used mailing-lists and I'm still using some sometimes. That's
> why I try to avoid them.
> do not need to subscribe
>
> If you're interested in learning this assumption has already been
> questioned and discussed a million times on this site - and others.
>
> Random example: https://lwn.net/Articles/817668/
https://discourse.debian.net exists. I have never used Discourse but
I'd gladly start if there was a need but e-mail would still be
better. I can use both - no problem for me but I see that some
self-called "modern" people (not you) are rather close-minded and
inflexible.
> whole too. "Blame" Facebook, Whatsapp and what not.
out this evening, I use Signal. But e-mail loosing steam? Maybe but
I'm not sure it will stop being relevant until the end of my "career"
but I wouldn't be so sure about Facebooks, Whatsapps and other today's
rockstars. At least, e-mail serves as a login/registration mechanism
and notification system in many places. It's still widely used in
business because it's versatile, unified, independent and secure (but
only if set up correctly).
> > If you don't know how to use a mailing list you will never contribute to
> Linux or Freebsd kernels or projects such as busybox, U-boot and others.
>
> Exactly one of the top issues that has already been discussed a million
> times, welcome to the party. Better late than never.
contribute.
Toward a "modern" Emacs
Toward a "modern" Emacs
>
> > Well, if someone cannot figure out how to use e-mail they'd better not
> contribute.
>
> s/figure out/like/
>
> I know how to use email;
e-mail - I meant that if someone wants to contribute to a project that
uses e-mail they should be intellectually able to figure out how to
use their e-mail client, git-send-mail and git-am. Well, I did and I'm
not the smartest person in the world, I'm actually quite dumb.
> and retrieve them on port 110 (before everything became encrypted).
K-9 Mail on the daily basis.
> disorganized and not productive.
good searching capabilities: I can filter e-mails by From: or To:
headers, by subject, by e-mail body; I can move e-mails to other
mailboxes; can easily backup my ~/.muttmail even though all messages
are also kept on the server; I'm notified about new e-mails on my
phone; I can read and reply to e-mails on my phone and thanks to IMAP
they are synchronized with mutt) and productive - I don't have to
leave command line and since I use Emacs to write the body I have
access to all existing buffers as I explained above.
> temptation not to make too easy to contribute but seriously: use email
> because you think it's the best way for the project to communicate, not
> because there are technically easier ways to communicate!?
forms technically use to use though slightly less convenient because I
hate using mouse (I'm using tridactyl in Firefox to overcome this
problem) and because web based forums are not so flexible, cannot be
backed up locally and do not provide as good searching capabilities as
mutt does. So yes, I find e-mail the best way for the project to
communicate.
> like email but not this kind of attitude and to be honest it lowers
> the credit of other, much better points you made. Don't mix up two
> totally different problems.
> time is not to start reviewing anything until all tests and checks pass in
> CI (or have a very good, written justification why they don't).
> perform something actually useful and relevant: reproduce and
> troubleshoot failures and fix them. If no CI failure (for instance
> because of lack of test coverage), asking for new tests is another
> much better litmus test.
mailing lists? There might be - there is one on LKML for example, and
they also have a web based interface that shows all patches sent,
their state and shows the discussion
https://lore.kernel.org/patchwork/project/lkml/list (I heard managers
like it this way).
> test carries a "monoculture" risk.
>
> In general creating an artificial shortage of contributors because there is
> a shortage of maintainers is playing with fire from a long term, natural
> selection perspective, so proceed very carefully
how did you come to this conclusion. What if project A uses Github but
someone who wants to contribute used to work for years in project B
that uses Gerrit and doesn't know how Github works (and these 2 tools
are really different technically) - is project A intentionally
creating shortage of contributors this way?
> retirement at great expense would be risky ;-)
retirement age. I expect to see a lot of breakthrough changes, new
ways of doing things, new ideas and adapt to all of them. Just a few
months ago I switched to i3 to be ready to switch to Sway on Wayland
and a few days ago I got a new M.2 SSD disk, much faster than the ones
I have used so far. I'm not and am not planning on being stuck in the
past.
> purposely rely on a litmus test as bad as "Do you like email?"
Toward a "modern" Emacs
> > purposely rely on a litmus test as bad as "Do you like email?"
Toward a "modern" Emacs
>
> > Everybody does. And I didn't mean that YOU don't know how to use e-mail -
> I meant that if someone wants to contribute to a project that uses e-mail
> they should be intellectually able to figure out how to use their e-mail
> client, git-send-mail and git-am.
>
> This is not really about configuring an email client or using git. It's
> about organizing the information overload you're describing:
body. How is this different from anything else?
> good searching capabilities: I can filter e-mails by From: or To: headers,
> by subject, by e-mail body; I can move e-mails to other mailboxes; can
> easily backup my ~/.muttmail even though all messages are also kept on the
> server;
>
> I prefer not having to do most of these _at all_.
not having to do? You prefer not doing backup ("there are two kinds of
people...")? You prefer not having easy searching by author or
subject? You prefer not using your smartphone? You prefer not using
the command line? You hate synchronization and notifications?
different people, don't you think? For instance, I find Gmail flashy
clicky web interface absolutely disgusting and unusable.
> > As I explained, I find e-mail technically easy to use.
>
> Great but this discussion isn't about you cause you already prefer email.
> temptation not to make too easy to contribute but seriously: use email
> because you think it's the best way for the project to communicate, not
> because there are technically easier ways to communicate!?
> convenient because I hate using mouse
>
> You just hit the second most common misconception in this discussion. While
> the web is clearly the preferred database interface these days, there's no
> fundamental requirement for it to be. If some people manage to get
> something out of github from Emacs (github = the closed source poster child
> of open source), surely it's possible to do even better with alternatives
> to github.
Github from Emacs. You can use Github like a regular repository and
you can use hub command line tool to fork and push pull requests
etc. and you can read and reply to all tickets by e-mail.
> lists?
>
> Again, no idea how you got that. Information overload?
use e-mail to register. Yes, I've used Gerrit, Gitlab, Github and
Bitbucket. I also use StackExchange a lot (Emacs has a very nice
Markdown mode) - it's heavily web based. But what's the point? I have
used many different things, have self-called "modern" developers too?
> > > purposely rely on a litmus test as bad as "Do you like email?"
>
> > I don't do that.
>
> I'm pretty sure you just did.
the rules. You don't have to like them, it's not your project.
> less and read more (and more slowly).
posts. They're patronizing and written in a very bizarre way.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
> improvement _for the existing team_
>
> Totally agreed - as long the existing team doesn't "live under a rock",
> doesn't place non-technical objectives too far above technical ones and can
> generally listen to unusual perspectives.
any patches but I'm glad they think about the future, I'd like to see
how Emacs evolves in the next decades. I also described how Emacs
fills all of my needs as a programmer in year 2020, mentioned Emacs SE
(I forgot r/emacs) and stated that there are many other projects that
use e-email and that you should know how to use it. You somehow
focused on that e-mail thing and started convincing me that it's very
very bad and should not be used. Nobody "lives under the rock" here.
> fork or look for alternatives and not just for tooling reasons.
other times if there is a need. For me, making it work on Wayland
without using XWayland is now one of the most important things to
do. I'd gladly start using Wayland on the daily basis without any
leftovers from X.
> justifies it is to "fragment and bridge" the tooling, this is what happens
> for the kernel for instance.
(actually, most OS projects are smaller than kernel). It's also not as
critical and there are not so many eyeballs looking at it.
Toward a "modern" Emacs
So I have been using vi(m) since the 1990s and emacs since about 2003. This article and the comments are very interesting. Here is my take
Toward a "modern" Emacs
I feel emacs still has its place today and younger coders should discover it; and it wouldn't hurt to make the learning process less steep.
Toward a "modern" Emacs
Toward a "modern" Emacs
Toward a "modern" Emacs
187 comments and nobody has mentioned Xah Lee's efforts at modernization (http://ergoemacs.org/emacs/emacs_modernization.html), or the (basically failed) XEmacs fork?
Toward a "modern" Emacs
Toward a "modern" Emacs
Compatibility is important
Compatibility is important
Toward a "modern" Emacs
BTW, Centaur Emacs https://github.com/seagle0128/.emacs.d/ are available for FSF.