No such file or directory - /Users/t/xiki/misc/logs/difflog.notes

[thams]

From command line, did
% xsh -e

and got this:

edited/

• tried to run:
  : # /, so show the list...
  :
  : files = DiffLog.file_list :tree_format=>1
  : txt = files.join "\n"
• error:
  | No such file or directory - /Users/t/xiki/misc/logs/difflog.notes
  | Errno::ENOENT
• backtrace:
  =/Users/t/xiki-master/lib/xiki/core/diff_log.rb:675:in read' =/Users/t/xiki-master/lib/xiki/core/diff_log.rb:675:infile_list'
  =/Users/t/xiki-master/commands/edited.rb:3:in eval_inner' =/Users/t/xiki-master/lib/xiki/core/code.rb:299:inmodule_eval'
  =/Users/t/xiki-master/lib/xiki/core/code.rb:299:in eval_inner' =/Users/t/xiki-master/lib/xiki/core/code.rb:261:ineval'
  =/Users/t/xiki-master/lib/xiki/handlers/ruby_handler.rb:30:in handle_script' =/Users/t/xiki-master/lib/xiki/handlers/ruby_handler.rb:19:inhandle'
  =/Users/t/xiki-master/lib/xiki/core/menu.rb:1015:in `block in handle'

[trogdoro]

That's a bug that will happen when:

• You try to view recently edited files
  • (what the "edited/" command is trying to do)
• You haven't yet edited (and saved) any files in using xsh

Thanks for discovering the bug. I fixed it locally. I'll be doing a big
push in a few weeks that'll make xsh much friendlier. And it'll have the
central xiki repository, which I think is going to be amazing!

--Craig

On Thu, Oct 29, 2015 at 10:54 AM, Kurt Thams notifications@github.com
wrote:

From command line, did
% xsh -e

and got this:

edited/

• tried to run: : # /, so show the list... : : files =
  DiffLog.file_list :tree_format=>1 : txt = files.join "\n"
• error: | No such file or directory -
  /Users/t/xiki/misc/logs/difflog.notes | Errno::ENOENT
• backtrace: =/Users/t/xiki-master/lib/xiki/core/diff_log.rb:675:in read'
  =/Users/t/xiki-master/lib/xiki/core/diff_log.rb:675:infile_list'
  =/Users/t/xiki-master/commands/edited.rb:3:in eval_inner'
  =/Users/t/xiki-master/lib/xiki/core/code.rb:299:inmodule_eval'
  =/Users/t/xiki-master/lib/xiki/core/code.rb:299:in eval_inner'
  =/Users/t/xiki-master/lib/xiki/core/code.rb:261:ineval'
  =/Users/t/xiki-master/lib/xiki/handlers/ruby_handler.rb:30:in handle_script'
  =/Users/t/xiki-master/lib/xiki/handlers/ruby_handler.rb:19:inhandle'
  =/Users/t/xiki-master/lib/xiki/core/menu.rb:1015:in `block in handle'

—
Reply to this email directly or view it on GitHub
#152.

[thams]

So then... dumb question... how does one save an edited file using xsh? C-x C-s doesn't seem to work because the C-x appears to be trying to do a Xiki execution.

[trogdoro]

You can always type Ctrl+K to see the key shortcuts. In the un-pushed
version of xsh it makes this more obvious. By always showing "Keys" (with
the K underlined) in the bottom bar, even when you're viewing a file.

I think in the version out on github saving is Ctrl+W Ctrl+S. Think of it
as "window+save".

--Craig

On Thu, Oct 29, 2015 at 3:20 PM, Kurt Thams notifications@github.com
wrote:

So then... dumb question... how does one save an edited file using xsh?
C-x C-s doesn't seem to work because the C-x appears to be trying to do a
Xiki execution.

—
Reply to this email directly or view it on GitHub
#152 (comment).

[trogdoro]

From command line, did
% xsh -e

Ah, I just figured out you probably typed "xsh -e" because of:

$ xsh --help
| -e Examples

I fixed that. It's now:

$ xsh --help
| -e Edited recently

Please use "xsh --examples" to see examples:

$ xsh --help
| Examples:
| $ xsh --examples

Some of the examples are probably out of date - I've changed a ton of flags
and key shortcuts recently. But on the up side, things are finally
solidifying, and there will be fewer drastic changes after this next push.

--Craig

On Fri, Oct 30, 2015 at 8:56 AM, Craig Muth craig.muth@gmail.com wrote:

You can always type Ctrl+K to see the key shortcuts. In the un-pushed
version of xsh it makes this more obvious. By always showing "Keys" (with
the K underlined) in the bottom bar, even when you're viewing a file.

I think in the version out on github saving is Ctrl+W Ctrl+S. Think of it
as "window+save".

--Craig

On Thu, Oct 29, 2015 at 3:20 PM, Kurt Thams notifications@github.com
wrote:

So then... dumb question... how does one save an edited file using xsh?
C-x C-s doesn't seem to work because the C-x appears to be trying to do a
Xiki execution.

—
Reply to this email directly or view it on GitHub
#152 (comment).

[thams]

Yes, that was how I got there. Thanks for the clarification.

Let me know when you've got the new version out; I'll do pull-requests as I find things that would make the examples read more easily.

[thams]

FWIW, I'm still confused about when ESC takes you logically back a screen, and when it doesn't.

[trogdoro]

It'll be a few weeks until I do the next push, unfortunately.

confused about when ESC takes you logically back a screen, and when it
doesn't

Generally, if you have something going on on the screen (a filter, a
search, a key shortcut menu) esc cancels out of it. If you don't have
anything going on, esc switches to the last view.

I'll be curious to hear if you get used to this over time. I need to pair
with more people and observe them using it and make tweaks accordingly.

I've watched a few people use it over the last few months, and I'm happy to
say they have a waaay better experience than with the old behavior of esc.
I used to have esc do the default emacs thing and it confused the heck out
of people. They would hit escape to try to cancel or close something, and
that would make the next key they typed be an unexpected key shortcut that
would often get them further into trouble rather than out of trouble. At
that point, users often decided Xsh key shortcuts were too confusing for
them. It took a lot of work to get esc to act in a partly sane way :)

--Craig

On Fri, Oct 30, 2015 at 10:33 AM, Kurt Thams notifications@github.com
wrote:

FWIW, I'm still confused about when ESC takes you logically back a screen,
and when it doesn't.

—
Reply to this email directly or view it on GitHub
#152 (comment).

[thams]

Well, there are many examples where ESC does neither... it just stays put. That's where I get confused.

For example:

xsh
c-t to get Tasks

$
  ~ examples/
    - git/
      - log/
        - one line/
          $ git log --oneline

Expand successively down through these to execute $ git log --oneline

that produces this:

$ git log --oneline
  | a83834 such a nice commit

But then from there, ESC does nothing.

[trogdoro]

$ git log --oneline

When you expand something in Xiki, it lets you type to filter down the
output (this is indicated in the bottom bar). When you type esc (or an
arrow key etc), it cancels the filter (the bottom bar changes to reflect
this). If you hit another esc after that, it should switch the views.

In your case though I'm not sure. If there's only one line of output the
filter doesn't happen (not sure if you deleted the other lines).

Btw your indenting isn't coming through in the emails or github issues. I
edited your comments to have the examples start with 4 spaces instead of
two, and that seemed to fix it. Using the "Preview" tab on github lets you
see what they'll look like, after the weird mandatory formatting they do.

--Craig

On Fri, Oct 30, 2015 at 11:15 AM, Kurt Thams notifications@github.com
wrote:

Well, there are many examples where ESC does neither... it just stays put.
That's where I get confused.

For example:

xsh
c-t to get Tasks

$
~ examples/

• git/
• log/
• one line/
  $ git log --oneline

Expand successively down through these to execute $ git log --oneline

that produces this:

$ git log --oneline
| a83834 such a nice commit

But then from there, ESC does nothing.

—
Reply to this email directly or view it on GitHub
#152 (comment).