xemacsweb / About / XEmacsVsGNUemacs.content

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
%title%
XEmacs vs. GNU Emacs
%author%
Stephen Turnbull <stephen@xemacs.org>
%main%

  <h1>XEmacs vs. GNU Emacs</h1>

  <p>
    <em>
      Much of this page was written over a decade ago, by somebody
      other than the current editor, possibly Ben Wing.  The previous
      major revision occurred on January 1, 2001, by me.  GNU Emacs
      has improved a fair amount, but the irreconcilable differences
      between the projects continue, with no resolution in sight.  I
      have little interest in learning enough technical details about
      GNU Emacs 22 to accurately revise it, so you should take
      everything in square brackets with a grain of salt. -- stephen,
      February 19, 2008
    </em>
  </p>

  <p>
    There are currently irreconcilable differences in the views about
    technical, programming, design and organizational matters between
    Richard Stallman (RMS) and the XEmacs development team which provide
    little hope for a merge to take place in the short-term future.
  </p>

  <p>
    If you have a comment regarding a merge, it is a good idea to
    avoid posting to the newsgroups, because of the very heated
    flamewars that often result.  Mail your questions to <a
      href="mailto:xemacs-beta@xemacs.org">xemacs-beta@xemacs.org</a>
    and <a href="mailto:emacs-devel@gnu.og">emacs-devel@gnu.org</a>.
  </p>

  <p>
    Many people have noticed the great difference in focus between the
    two "Viewpoints" presented here, and also have expressed confusion
    about the legal issues RMS focuses on.  The final sections
    present some explanation and interpretation regarding these FAQs.
  </p>

  <h2>
    Technical Differences between XEmacs and GNU Emacs<br />
    (the XEmacs Point of View)
  </h2>

  <p>
    This section is now quite dated.  Much of it refers to GNU Emacs
    19 and XEmacs 20.  However, many of the differences described persist in
    the most recent versions of both Emacsen in some form.
  </p>

  <h3>User-Visible Editing Features</h3>

  <p>
    As of GNU Emacs 22, XEmacs's GUI features (images, variable pitch
    fonts, widgets) are reported by some GNU Emacs users to be more
    efficient and usable than GNU Emacs's.
  </p>

  <p>
    <!-- #### Is this obsolete? --> XEmacs provides support for
    ToolTalk on systems that have it.  <!-- #### Possibly I should
    drop mention of DnD? --> Experimental support for drag-and-drop
    protocols is provided from XEmacs 21.  [Not available in GNU Emacs
    21.  Status in GNU Emacs 22 unknown.]
  </p>

  <p>
    XEmacs has a built-in toolbar.  Four toolbars can actually be
    configured simultaneously: top, bottom, left, and right toolbars.
    [A single toolbar was added to GNU Emacs 21.]
  </p>

  <h3>General Platform Support</h3>

  <p>
    Starting with XEmacs 21.4, if your platform supports dynamically
    loadable modules, so does XEmacs.  RMS continues to refuse to
    allow this facility in GNU Emacs, because it makes it easier to
    distribute modules in violation of the GPL.
  </p>

  <p>
    If you're running on a machine with audio hardware, you can
    specify sound files for XEmacs to play instead of the default X
    beep.  See the documentation of the function load-sound-file and
    the variable sound-alist.  XEmacs also supports the network sound
    protocols NAS and EsounD.  [Not available in GNU Emacs 22.]
  </p>

  <p>
    XEmacs 21 supports database protocols with LISP bindings,
    currently including Berkeley DB, LDAP, and PostgreSQL (from 21.4).
    [Not available in GNU Emacs 22.]
  </p>

  <p>
    XEmacs 21 supports the Canna, Wnn, and SJ3 Japanese input
    method servers directly, as well as through the X Input Method
    (XIM) protocol.  GNU Emacs 22 supports only the XIM protocol,
    although there are now pure Lisp implementations of Canna and Wnn.
    Both Emacsen support the Quail family of input methods
    (implemented in LISP) for many languages.
  </p>

  <p>
    As of XEmacs 21.4, although XEmacs supports preloaded Lisp using
    "unexec", it is considered obsolete.  XEmacs 21.4 uses a much more
    portable technique to "dump" and "preload" Lisp.  GNU Emacs 22
    still uses unexec.
  </p>

  <p>
    XEmacs 21 supports multiple frames on TTYs.  GNU Emacs is
    scheduled to get that feature in version 23.
  </p>

  <h3>Packaged LISP Libraries</h3>

  <p>
    Many more packages are provided standard with XEmacs than with GNU
    Emacs 22.
  </p>

  <p>
    XEmacs 21 supports an integrated package management system which
    uses EFS to download, then automatically install prebuilt LISP
    libraries.  This allows XEmacs users much more straightforward
    access to the "latest and greatest" version of any given library.
  </p>

  <h3>LISP Programming</h3>

  <p>
    From XEmacs 20 on, characters are a separate type.  Characters can
    be converted to integers (and many integers can be converted to
    characters), but characters are not integers.  GNU Emacs 19,
    XEmacs 19, Mule 2.3 (an extensive patch to GNU Emacs 18.55 and
    19.x), and GNU Emacs 20--22 (incorporating Mule 3 and later Mule 4)
    represent them as integers.  [GNU Emacs 23 may get a character type.]
  </p>

  <p>
    From XEmacs 20 on, the buffer is treated as an array of
    characters, and the representation of buffer text is not exposed
    to LISP.  The GNU Emacs 20--22 functions like buffer-as-multibyte are
    not supported.
  </p>

  <p>
    In XEmacs, events are first-class objects.  GNU Emacs 19
    represents them as integers, which obscures the differences
    between a key gesture and the ancient ASCII code used to represent
    a particular overlapping subset of them.
  </p>

  <p>
    In XEmacs, keymaps are first-class opaque objects.  GNU Emacs 19
    represents them as complicated combinations of association lists
    and vectors.  If you use the advertised functional interface to
    manipulation of keymaps, the same code will work in XEmacs, GNU
    Emacs 18, and GNU Emacs 19; if your code depends on the underlying
    implementation of keymaps, it will not.
  </p>

  <p>
    XEmacs uses "extents" to represent all non-textual aspects of
    buffers; GNU Emacs 19 uses two distinct objects, "text properties"
    and "overlays", which divide up the functionality between them.
    Extents are a superset of the union of the functionality of the
    two GNU Emacs data types.  The full GNU Emacs 19 interface to text
    properties and overlays is supported in XEmacs (with extents being
    the underlying representation).
  </p>

  <p>
    Extents can be made to be copied into strings, and then restored,
    by kill and yank.  Thus, one can specify this behavior on either
    "extents" or "text properties", whereas in GNU Emacs 19 text
    properties always have this behavior and overlays never do.
  </p>

  <h3>Window System Programming Interface</h3>

  <p>
    XEmacs supports Motif applications, generic Xt (e.g. Athena)
    applications, and raw Xlib applications.  An XEmacs variant which
    supports GTK+ is available (integration as an option in the XEmacs
    mainline is planned for XEmacs 22), although code to take
    advantage of the support is as yet scarce.  XEmacs does not
    support raw Xlib.  GNU Emacs 22 supports Xlib, GTK+, and MS
    Windows, with 3rd party or experimental support for Carbon and
    Cocoa on the Mac.
  </p>

  <p>
    XEmacs provides an interface called the "native widget API" for
    adding new kinds of widgets (currently including progress bars, tab
    controls, and buttons) which can be attached to extents using the
    image API.  GNU Emacs does not.
  </p>

  <p>
    As a compile-time option, an XEmacs frame can be placed within an
    "external client widget" managed by another application.  This
    allows an application to use an XEmacs frame as its text pane
    rather than the standard Text widget that is provided with Motif
    or Athena.
  </p>

  <h3>Community Participation</h3>

  <p>
    Starting with XEmacs 20, joining the XEmacs development team is
    simple.  Mail to <a href="mailto:xemacs-beta@xemacs.org">XEmacs
      Developers &lt;xemacs-beta@xemacs.org&gt;</a>, and you're in!  (If
    you <em>want</em> to be, of course.  You're also welcome to just
    post development-related questions and bug reports.)  As of
    February 2008, XEmacs has a
    <a href="http://tracker.xemacs.org/">modern bug tracker</a>.
    The GNU Emacs development lists were opened up as of the version
    21 development cycle, and a bug tracking system is under discussion.
  </p>

  <p>
    The XEmacs source code is managed using <a
    href="http://www.xemacs.org/Develop/hgaccess.html">Mercurial</a>,
    whereas the GNU Emacs source code is managed using Bazaar.
  </p>

  <p>
    In XEmacs,
    development and maintenance of Lisp libraries is separated from
    the core editor development at a fairly low level.  This provides
    better modularization and a better division of responsibility
    between external library maintainers and the XEmacs core
    development team.  Even for packages the size of Gnus, XEmacs
    users normally have access to a pre-built version within a few
    weeks of a major release, and minor updates often within days.
    RMS once again vetoed provision of a package system for Emacs in
    December 2007.
  </p>

  <p>
    In XEmacs,
    CVS commit authority is broadly dispersed.  Recognized maintainers
    of LISP libraries who are willing to maintain XEmacs packaged
    versions automatically qualify for CVS accounts for their
    packages.  Something similar is true for GNU Emacs at the time of
    writing.
  </p>

  <h2>The FSF Point of View</h2>

  <p><a href="mailto:rms@gnu.org">Richard Stallman</a> writes:</p>

  <blockquote>

    <p>
      XEmacs is GNU software because it's a modified version of a GNU
      program.  And it is GNU software because the FSF is the
      copyright holder for most of it, and therefore the legal
      responsibility for protecting its free status falls on us
      whether we want it or not.  This is why the term "GNU XEmacs" is
      legitimate.
    </p>

    <p>
      But in another sense it is not GNU software, because we can't
      use XEmacs in the GNU system: using it would mean paying a price
      in terms of our ability to enforce the GPL.  Some of the people
      who have worked on XEmacs have not provided, and have not asked
      other contributors to provide, the legal papers to help us
      enforce the GPL.  I have managed to get legal papers for some
      parts myself, but most of the XEmacs developers have not helped
      me get them.
    </p>

    <p>
      XEmacs was possible because free software means that anyone can
      change it and distribute a modified version.  I have no regrets
      about establishing this freedom for Emacs.  Everyone should have
      the freedom to change any program, and this is not limited to
      changes that the original author likes.
    </p>

    <p>
      Many people have taken advantage of the freedom to change GNU
      Emacs, over the last decade.  Most of them were willing to
      cooperate on integrating their changes into Emacs.  XEmacs arose
      as a separate forked version because some of the
      developers--starting with Zawinski--were unwilling to do that.
    </p>

    <p>
      People should have the freedom to decide what to work on,
      including the freedom to compete with the GNU project, but it's
      a shame when they make that choice.  The whole community loses
      when someone chooses competition rather than cooperation.
    </p>

    <p>
      But this is worse than competition--it is unfair competition.
      The XEmacs developers can and do copy code they like from Emacs.
      If I could copy the code I like from XEmacs in the same way, at
      least the rivalry would be fair.  But I can't do that, because
      substantial parts of XEmacs don't have legal papers, or don't
      have known authors.
    </p>

    <p>
      As long as we cannot use XEmacs in the GNU system, the GNU
      project has to make sure that Emacs is not left behind.  In
      other words, we have to behave like rivals too, even though we
      wish there were no rivalry.  When XEmacs developers try to
      persuade people to use, test, fix and enhance XEmacs instead of
      Emacs, the GNU project can't sit still; we need them to use,
      test, fix and enhance Emacs instead.
    </p>

    <p>
      There is good code in XEmacs, which I'd be happy to have in a
      merged Emacs any day.  But I cannot copy it out of XEmacs myself
      because of the uncertain authorship and/or lack of legal papers.
    </p>

    <p>
      This problem could probably be resolved, at least for large
      parts of XEmacs, with substantial help from the authors of that
      code.  Otherwise, the GNU project has to write or find
      replacements for it.
    </p>

    <p>
      I invite people who like Emacs, and want the best possible
      version of Emacs to be available for use in the GNU system, to
      help in one way or the other.
    </p>

  </blockquote>

  <!-- #### This really isn't source for the RMS quote.  Obsolete?
  Does anyone know where that came from?  If not, this can go.

  <p><strong>Sources:</strong> <a href="http://www.xemacs.org/FAQ/">FAQ</a>
  item 1.0.5, and XEmacs 21.0 NEWS file

  -->

  <h2>What Is the Legal Issue?</h2>

  <p>
    There is no difference in the nature of the copyrights or licenses
    of the two projects.  Copyright is defined by law and
    international treaty, and is automatically awarded to the author
    as soon as a work is published.  Both projects use the GNU General
    Public License to protect their work while providing it freely to
    the community.  (GNU Emacs moved to GPL version 3 almost as soon
    as it was available; XEmacs is moving in that direction as well.
    Of course since XEmacs is licensed under "GPL version 2 or later,"
    individuals who wish to redistribute XEmacs under version 3 can do
    so.  Thus this is not a real difference.)
  </p>

  <p>
    XEmacs has no choice, because much of its code is copyrighted by
    the Free Software Foundation, and is only available to XEmacs
    under the GPL.  Under that license, redistribution is only
    possible under the GPL.  The GNU Project uses the GPL as a matter
    of principle.  (XEmacs developers generally subscribe to a similar
    principle, of course.)  It is the same GPL, so sharing code is
    100% legal.
  </p>

  <p>
    However, copyright is governed by the <em>civil</em> code, not the
    criminal code.  This means that the government takes no interest
    in violations of copyright as such.  It only undertakes to provide
    law courts where the copyright can be enforced.  It is the
    responsibility of the copyright holder to sue to prevent
    violations and receive damages for past violations.  The
    government <em>cannot</em> act on the complaints of third parties.
  </p>

  <p>
    The FSF has received legal advice that a copyright holder in a
    jointly-authored work is in a weak position to enforce its
    copyright unless all coauthors participate in the legal action.
    Evidently the FSF would be considered a third party with respect
    to non-assigned code, weakening its ability to defend the whole
    work.  (Author's note: You'd have to ask a lawyer why that might
    be so.  I am not an expert, but lawyers I have asked informally
    agree that this theory is plausible, although it has not been
    tested in court.  It may also be more or less applicable in
    jurisdictions other than the U.S.)
  </p>

  <p>
    Based on this advice, RMS has concluded that incorporating
    <em>some</em> code copyrighted by another entity into a work such
    as Emacs puts the copyright of <em>all</em> of the work at risk of
    being unenforceable in court in the case of a violation.  He has
    judged that this risk is unacceptably large.  Therefore he insists
    that the whole copyright of any software that included in the GNU
    system be assigned to the FSF, with few exceptions.
  </p>

  <h3>What Is the Role of the FSF?</h3>

  <p>
    RMS believes that copyright in software itself is immoral.
    Copyleft is a device to undermine the whole idea.  He has little
    empathy for people who wish to retain copyright---after all, he
    has given up his own.  This is the fundamental idea behind the FSF
    (as opposed to the GNU Project, which actually develops software).
    It is a holding company for all the software copyrights that
    shouldn't even exist in the first place.  According to the legal
    argument above, such a trust is necessary to defend the GPL. It is
    the GPL that prevents proprietary firms from misappropriating the
    software at the same time as it prevents the holding company (the
    FSF) from being a monopoly.
  </p>

  <h2>Well, Isn't That Paranoid?</h2>

  <p>
    Many developers think so, but it seems that no one who holds a
    different theory has retained a lawyer to check the precedents.
    The FSF has done so, so its position must be considered most
    credible.
  </p>

  <p>
    Also, it is important to remember that RMS and the FSF are not (in
    this context) acting as software developers.  Rather, they
    perceive themselves as guardians of a social movement.  Their
    responsibility is not to any one application or project, but to
    the whole GNU system.  For that reason as well, a conservative
    approach can be justified.
  </p>

  <h3>Don't the XEmacs Developers Care?</h3>

  <p>
    Of course we do.  But even if we haven't consulted a lawyer, we
    have the right to judge the risks to our own product.  Most of us
    consider it low.  Furthermore, many XEmacs developers take a
    different approach to the free software movement itself, and so
    will differ from GNU/FSF policy.  The code <em>we</em> write will
    remain free.  What we are possibly losing is the ability to
    <em>force others</em> to make their modifications free.  This is
    central to the GNU Project because it is a social movement.  To
    many developers as individuals, it is not so crucial.
  </p>

  <p>
    This also shows why the "Viewpoints" are so different in style.
    XEmacs developers consider their project from a technical point of
    view, and prefer it for technical reasons.  They see their
    contributions to the free software movement as stemming from their
    development and publication of code.  Richard Stallman, and the FSF,
    consider their primary role to be more politically and socially
    oriented.  Thus social and legal issues come to the fore.
  </p>

  <h2>Fear of Forking Considered Harmful</h2>

  <p>
    Few XEmacs developers consider having multiple implementations of
    some features a bad thing.  The original Lucid fork arose, as RMS
    writes, because the Lucid developers (primarily Jamie Zawinski)
    would not "cooperate" in merging the Lucid code into the GNU
    mainline.  What RMS does not mention is that in his vision of
    "cooperation" the Lucid developers would be working under
    <em>his</em> direction to merge those features that <em>he</em>
    wanted, making changes to <em>their</em> code as <em>he</em>
    directed.  This is obvious, when you think about it.  Of course he
    was the head of the GNU Emacs project, and would reserve the right
    to make final decisions.  Nor is it surprising that the Lucid
    developers refused.  They had egos, of course.  But ... well, you
    can, and should,
    <a href="http://www.jwz.org/doc/lemacs.html">judge for yourself</a>.
  </p>

  <p>
    But there were also those "irreconcilable technical differences."
    Both Lucid Emacs and GNU Emacs 19 were excellent editors, but in
    their different ways.  The Lucid developers honestly considered
    GNU Emacs 19, and the merge as outlined by RMS, to be broken in
    some important ways.  He, just as honestly, considered many of the
    changes the Lucid developers demanded to be broken, or at best to
    be fixing what wasn't broken.  A fork was inevitable.  That's one
    thing free software is for: the right to fix what <em>you</em>
    consider broken, and redistribute the improvements.
  </p>

  <p>
    And a little competition may be good for you!  Without the fork,
    GNU Emacs 20 <em>might</em> not have added Mule, and GNU Emacs 21
    might <em>not</em> have the GUI redisplay.  Who knows when GNU
    Emacs will get a library packaging system?  All of these features
    were successfully pioneered by Lucid Emacs or XEmacs.  They were
    implemented at times when RMS considered them broken, irrelevant,
    or low priority.  Conversely, not only is XEmacs based on GNU
    Emacs, but part of the development effort includes regular
    synchronization of features and implementations with the mainline
    versions.
  </p>

  <p>
    Of course, we all think it is best when all the good code that
    results can be shared:
  </p>

  <blockquote>
    All Emacs developers are free software developers.
  </blockquote>

  <p>
    But whether or not it <em>can</em> be shared is a matter of point
    of view.  And the question is quite extraneous to the development
    process itself.  "How much does the legal system hinder you in
    effectively protecting your copyright when you cooperate with
    someone unwilling to give up their copyright?"  Maybe you don't
    need to care.
  </p>

  <h3>Author's Disclaimer</h3>

  <p>
    I disagree strongly with the FSF position in many respects.  In
    fact it is my personal opinion that in interactions with XEmacs
    developers RMS has been more interested in recruiting them to do
    work he wants done on Emacs, than in acquiring XEmacs code with
    far less effort than it would take to develop it from scratch.
  </p>

  <p>
    However, I have tried to present the facts of the legal issue as
    accurately and objectively as possible, and have some hope I
    succeeded.  The interpretation of why XEmacs developers as a group
    do not worry about this legal issue is my own.  The most I can say
    is nobody on the XEmacs developer's mailing list has complained
    about it.
  </p>

  <p>
    Statements about what Richard Stallman believes, judges,
    concludes, and so on should be taken with a grain of salt.  I am
    not so foolish as to pretend to speak for him.  Rather, I have
    found certain conjectures useful for establishing a coherent
    interpretation of his actions and statements, and have taken the
    liberty of making them available to you.  The NO WARRANTY section
    of the GPL definitely applies to them, though!
  </p>

  <p>
    I just wanna say that I am proud that this page <em>still</em> gives
    <a href="http://www.jwz.org/">Jamie Zawinski</a> an
    excuse to use a <em>wonderful</em> word like
    <a href="http://www.jwz.org/doc/lemacs.html">pusillanimous.</a>
    There are plenty of venues where you can read endless flames on
    these issues.  With little effort, you can probably find some of
    mine.  This isn't one.  So big deal.
  </p>

  <address>
    Stephen J. Turnbull &lt;stephen@xemacs.org&gt;
  </address>

  <!-- Keep this comment at the end of the file
  Local variables:
  mode: xml
  sgml-omittag:nil
  sgml-shorttag:nil
  sgml-namecase-general:nil
  sgml-general-insert-case:lower
  sgml-minimize-attributes:nil
  sgml-always-quote-attributes:t
  sgml-indent-step:2
  sgml-indent-data:t
  sgml-parent-document:("../template.html" "html" "body" "table" "tr" "td")
  sgml-exposed-tags:nil
  sgml-local-catalogs:nil
  sgml-local-ecat-files:nil
  End:
  -->
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.