Would this work over a simple telnet/ssh connection?
I get the feeling it'll only work if the X display is forwarded to another machine.
Software developer and Google employee Daniel Colascione has cooked up what he calls “Buttery smooth Emacs” by adding rendering code to the venerable text editor that does away with long-standing flickering and resizing issues. Colascione took to Facebook to promise that his mod for Emacs adds “support for double-buffered …
This still seems back to front to me even a couple of hours after first reading about it. It should be up to the terminal software on the client computer to double buffer and/or repaint on vsync, that way it'd work for any connection type instead of one with X11 forwarding. All he's done is patch X Windows repainting so it looks less dreadful, which says more about X Windows than Emacs.
How could a terminal emulation double buffer? They're character oriented and half the character sets are control codes. After how many characters is that the end of the frame? How does the terminal know when to show its double buffer?
The way it's always been done, start painting the changes to the terminal window when the window contents are not being drawn on the monitor (i.e. the beam is just under the window contents). However most window managers are compositing these days.
Of course Emacs was never UNIX anything (GNU is not UNIX, fapping motion). Unlike ed or vi it was never under Berkeley or AT&T license and unlike the other two not mentioned in POSIX at all. Like bash its another GNU monstrosity that has wormed its way in to Linux and seldom much else by default. Good thing for GNU then that Red Hat is making sure there will be precious little else but Linux going forward.
The man pages for GNU are always hilariously passive aggressive on this point.
"If the documentation has been correctly installed at your site" is what I recall it saying. But I always imagined the real meaning to be something like
"If your sysadmin has drunk the entire bottle of GNU Kool-Aid, you can find an incredibly dense manual by typing ``info foo''. But if they are a normal person who just untarred and ran, well, dear peasant, you are stuck with this man page."
I seem to remember double-buffering was not needed on the zx80, a computer so primitive that it didn't have enough memory to store the whole display and could run out of memory if it had too much to display. It also didn't have enough hardware/processing power to keep the display going at the same time as doing any processing on anything else. Consequently every time you pressed a key, or a program ran for a bit, the display went off. This meant that you could have a program assemble the screen, and you wouldn't see anything happen until it stopped for user input. Great for an untidy redisplay of a screen, but not so good for things looking like they're moving about. Typical Sinclair shite in my opinion. The tech was there to have a screen that didn't flicker every time you pressed a key, but sinclair wanted to make the computer really cheap.
Trying to figure out just /why/ it ran out of memory and what to do about it was my first experience with figuring out how the internals of a computer really worked - like many people here, I suspect.
The fact that it was cheap got it, and the later Sinclair computers, into a lot of homes. The corners that had to be cut to make them cheap made for some great opportunities to introduce kids to real-world engineering.
I owned sinclair computers and that is precisely how I could afford my first computer. But the quality was incredibly poor. I was only 14 at the time and I was really upset at having to wait 3 or 4 months for the sodding zx81 to arrive, and then even more upset when it didn't work due to overheating. And then when I got the rampack, I began to see a pattern in quality control insofar as it had to remain absolutely still or the machine would crash. These things certainly taught me a lot. It taught me about sharp business practices, selling shit that didn't work right.
Later, when I had saved up enough for a sinclair QL, the quality hadn't improved much. It was advertised for sale before it had been designed! I bought one of the later "JS ROM" versions, which was a lot better, but the microdrives were a nightmare.
One thing that can be said about sinclair was that the software was on the whole good, and the manuals were excellent.
Then I got into PCs and found that the hardware was good but it was the software that was not so reliable.
The screen bounce on key press was, as you say, a consequence of the Z80 doing the screen rendering. Well, actually, it was being the display address counter - the ULA did the actual bit-shifting into the modulator.
The ZX81 had "slow mode" where the screen refresh was done under interrupt. Now the screen didn't bounce on key press, but the machine ran dog-slow as it only spent 20% of it's time actually running your program.
The technology is ancient - there's a summary here: http://laughtonelectronics.com/Arcana/KimKlone/BrideOfSon%20KK%20Lancaster.html
Emacs in a GUI? WTF?
Some of us use Emacs in a simple shell as God (aka Stallman) intended.
As I sit here, I have three Emacs sessions in three HD windows, each of those sessions have split screens as I debug some stupid Cordova notification code.
If I want to resize the windows I simply drag the window size and it resizes. No flickering and zero hassles. Works perfectly well.
Now I understand that certain people like to use a doo-hickie called a 'mousie' or something similar with their Emacs. Well, there is a ring of hell reserved for these heretics. I suspect this person who implemented 'dooble Booofering' might well be joining them shortly. Christ, they'll be adding colours next.
Bloody developers should not play with forces they don't understand....
Not sure, we use the local notifications plugin which worked well for us until IOS 10 and then it broke, There's a fork from EV that works so we use that, We also use the PushWoosh plugin. That also broke (badly) for IOS10. However to be fair to PushWoosh they worked with us pretty well to get the bug found and fixed.
We need both plugins to provide a sensible notification system that works when IOS and Android are both foreground, background, not started and to handle silent notifications for IOS and Android. Our use cases are pretty exacting :)
None of the plugins do this by themselves, especially the Android silent notifications, so we wrote our own hybrid system to do it all.
After saying that, notifications are by far the biggest chunk of code in our app. Handling the differences is a complete nightmare, hence we wrote our own hybrid to hide the pain,
Oh local notifications work. And I'll cut him some slack for iOS10. But it somehow modifies the `at` member of the structure so you can't reuse it. Then there's the whole not coalescing multiple schedule calls. And the cancellation architecture. And, as you say, the issue with foreground notifications not happening. And there are a whole bunch of PRs on the github page that should be in the mainline Android release. None of which bodes well for the source when I look at it. (Come to that, the work around for iOS10---set the alert to repeat---doesn't smell great; I hope that's down to Apple)
I'm not annoyed with the author; who's writing it in his weekends for free. But notifications are pivotal part of mobile. Cordova could do with getting their act together, particularly as there is a spec which Chrome implements on the desktop.
Anyway, it allowed us to gauge interest. We'll probably fork it next iteration and modify the java/objective C. By the sounds of it, you should probably be doing the same.
We've invested a hell of a lot of time in notifications as they are a core part of what our app does. I have to say that the support for notifications is pretty poor though across the board.
We've experimented with OneSignal, OpenShift and finally went to PushWoosh as they were the only ones that had a model that worked across Android and IOS, specifically at the time with silent notifications for IOS. They didn't do silent notifications for Android but they do that now, just that their documentation is about 10 years out of date so they didn't announce it or tell anybody. Their model wasn't great, but at least it worked. Hence we built our own notifications system that work the way we think that mobile notifications should work. Our system handles silent and rich foreground, background, suspended and app not started in a consistent single code base across IOS 8, 9, 10 as well as Android 5.0 and 6.0. Whilst we're rather pleased with it, we shouldn't need to write a framework like this, it should be standardised and open to all.
We don't get into the structure of the local notification, so hadn't picked up on the at modification. That doesn't sound good. We are aware of the limitations and are looking to see if PushWoosh can pick up the local notifications. However we're trying to keep our notification framework vendor neutral. So we keep an eye on OneSignal and every few months check we can use their systems if need be. We don't want to be too tied into a paid for vendor.
We'd seen the PR's on GitHub and as you say, it doesn't bode well. I hadn't checked the fix for IOS 10, I do suspect/hope/pray thats an Apple cock up.
We don't touch Objective-C or Java. We detest and hate Java and everything about it. We're C hackers really. We think Objective-C is OK-ish but far too high level for us :)
"I have three Emacs sessions"
But if you use the GUI version you only need 1 session with C-x 5 2 (make-frame).
As for a mouse with Emacs, I do like/love using nothing but a few mouse clicks to cut and paste a block of code, to non believers it looks like Jimi Hendrix playing his guitar with his teeth.
Agreed, each of my emacs sessions has multiple frames within it.
As I survey the disaster zone that is commonly known as my desktop, I can see three sessions, two of them are editing multiple docs within the same session, basically a split session with a total of six docs being carefully edited (or as my colleagues would say, hacked together with little regard for coding or professional standards).
Another is ssh'ed through a number of servers to run some tests in our servers located abroard.
Another is setting up test data on a different server. Again with multiple sessions.
Ctrl-X-2, 3, Ctrl X-b, Ctrl-X-o are well know key combinations. So much so, I had to stop and think what the actual keypresses are.
Whilst I could run everything in one window, I have three HD monitors so use them.
But I rely on the flickering! I hacked together a macro that triggers a predictable flash pattern. a Raspberry Pi on the other side of the room decodes the flickering to change between my Pandora streams by blaring a loud noise which causes my cat to scamper around the room, eventually stepping on an iPad in the corner.
#1172, if xkcd fans are having a GOMHAC moment...
I'm with those who run (g)emacs in text mode in an xterm. Don't need no bloody mousey stuff. I do have to fix the dang key bindings so that backspace and DEL work properly. My startup for emacs is this:
#!/bin/sh
xterm -cm -dc -rvc -ulc +bdc -bg "#c09060" -xrm 'XTerm.ttyModes: erase ^?' -e emacs
(And yes, I really do run my xterms with that tan background - I find it much easier on the eyes for long-term use than black on white.)