spacemacs icon indicating copy to clipboard operation
spacemacs copied to clipboard

On first screen, clicking on [links] does not open anything, inserts line break.

Open fidergo-stephane-gourichon opened this issue 4 years ago • 8 comments

Description :octocat:

On first screen, clicking on links (bracketed words "Homepage" "Documentation" etc) does not open anything, inserts line break.

Reproduction guide :beetle:

  • Make sure you have no .emacs.d or .spacemacs*
  • git clone https://github.com/syl20bnr/spacemacs optionally switch to develop branch
  • Start Emacs
  • Click on any of the bracketed words "Homepage" "Documentation".

Observed behaviour: :eyes: :broken_heart:

The word is broken as if a newline character is inserted at the position of the clicked character

See image. spacemacs_click_breaks

Expected behaviour: :heart: :smile:

  • Clicking on "Homepage" would show some spacemacs-related page.
  • Clicking on "Documentation" would show some spacemacs-related documentation. -Etc...

(%LAST_KEYS%) %SYSTEM_INFO%

Backtrace :paw_prints:

%BACKTRACE%

Additional information

  • Xubuntu 20.04 with plain X11 emacs packages, no customization.
  • Right after answering the questions "What is your preferred editing style?" and "What distribution of spacemacs would you like to start with?", clicking on the "links" produces no visible effect.
  • Once spacemacs has finished downloading 110 packages (wow), the same behavior can be observed.

It would seem that at the start of the install wizard the the home buffer allows editing.

Is it simple to hide these links until the installer has completed, as Spacemacs is not installed fully until the installer has completed and created a .spacemacs file (or a .spacemacs or .spacemacs.d/init.el file is manually added).

practicalli-johnny avatar May 06 '20 09:05 practicalli-johnny

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

github-actions[bot] avatar Jun 14 '21 14:06 github-actions[bot]

hiding home buffer links is a simple solution.

But this issue is of very, very, very low severity and only affect a very specific use case. that's why I think it's not fixed yet.

lebensterben avatar Jun 14 '21 14:06 lebensterben

Hi team!

Thanks for your attention on this bug.

Okay, minor bug, let's try again

From your comments I finally understood that the links are to be ignored. I thought they were the main place to start and a necessary path.

So, I started again, from the main README.md to give another try.

The result only reproduced that "spacemacs is totally broken from the start" feeling (which is certainly not true, I'm just describing the experience it gives).

A perspective from a new user (but seasoned emacs user)

I take from your answers that this bug looks pretty minor from your perspective. So, please look at the following simply as it is: a factual, no emotion, description of how it looks from user side.

From a newcomer perspective (an spacemacs newcomer, that is: I've been using emacs for nearly 25 years with a history of customization), here's how it looks:

  • Spacemacs wants to take over my .emacs.d, so I will lose all my customization (unless I do the full installation, but I start simple so I put my own config away temporarily, that's just a test drive)
  • A default emacs from a major Linux distribution (Ubuntu) does not seem like "a very specific use case", so I expect it to just work.
  • That bug happens again, starting the "totally broken" feeling described above. But I know I should ignore that, so let's do as if I didn't try to click on the first thing I see in the first buffer that appears.
  • I answer questions. First I'm on emacs not vi, so of course I'll want to start with emacs style, then only later if I'm convinced that spacemacs is so nice, maybe that day switch to vi style.
  • Buffers of warnings and compile logs with many errors appear (reproduced with master as well as develop, yes I tested both)
  • Many usual things seem to no longer work. For example, C-x o seemed not to work, but apparently it was only while the many packages loaded and compiled. Pressing backspace in file path removes whole components, why not but how do I remove only one character, etc.
  • Following https://www.spacemacs.org/doc/QUICK_START.html it's not clear what I win here.
  • vi-style key binding by default in all doc feels outlandish ... for a current emacs user (and probably not only me).
  • Wow, now even M-m doesn't work. Here's what M-x describe key says:

M-m runs the command back-to-indentation (found in global-map), which is an interactive compiled Lisp function.

It is bound to M-m.

(back-to-indentation)

Move point to the first non-whitespace character on this line.

Summary: lost what I had, didn't win anything

  • I feel that I lost the familiar emacs behavior.
  • It's not clear what I win here.
  • When I finally want to "explore the interactive list of carefully-chosen key bindings" with M-m which is apparently what I should understand when the doc says "press space", it doesn't even work.

So, I can't even start to taste the promised "sophisticated and polished set-up, focused on ergonomics, mnemonics and consistency."

A number of people might have found a nice place with a wonderful emacs setup, but starting from what I believe is a common situation and following instructions only leads to trouble after trouble.

Hope this helps. I may try a third time later, hoping that what is to be won is clearer and the path with less hassle.

Thank you for your attention.

From your comments I finally understood that the links are to be ignored. I thought they were the main place to start and a necessary path.

No I did not say that. During the initial setup, the focus should stay in the minibuffer until all questions are answered. This is the design. Therefore we do not expect user to jump out of the minibuffer and interact with other UI components. So I said hiding the home buffer (not only links) is a simple solution.

The result only reproduced that "spacemacs is totally broken from the start" feeling (which is certainly not true, I'm just describing the experience it gives).

This sense of "totally broken" is possible depending on your use case. There are known bugs not fixed and there are layers haven't received updates for years. But this is normal to open source projects.

From a newcomer perspective (an spacemacs newcomer, that is: I've been using emacs for nearly 25 years with a history of customization), here's how it looks:

Bear in mind that spacemacs never claim to have every one as target user. You feeling isn't lying to you. If you don't like it, you're just not one of the target user. Especially given that you're not a new user of emacs, and emacs is highly customizable, you shouldn't expect any community-driven framework to fit your specific needs, unless you're a phony seasoned user who doesn't customize emacs much.

* A default emacs from a major Linux distribution (Ubuntu) does not seem like "a very specific use case", so I expect it to just work.

Emacs and most of its functionalities are agnostic to host OS. So I don't understand your point here. Your distribution isn't relevant to whether your use case is general or not.

* That bug happens again, starting the "totally broken" feeling described above. But I know I should ignore that, so let's do as if I didn't try to click on the first thing I see in the first buffer that appears.

You should expect this behaviour. No one ever told you this is fixed. Actually I just commented this morning that this is not fixed.

* I answer questions. First I'm on emacs not vi, so of course I'll want to start with emacs style, then only later if I'm convinced that spacemacs is so nice, maybe that day switch to vi style.

When you choose emacs or hybrid editing style you're already not the main target audience. Good luck.

* Buffers of warnings and compile logs with many errors appear (reproduced with master as well as develop, yes I tested both)

This is not caused by Spacemacs. Most warnings are benign, such as using an obsolete variable, using an obsolete function calling convention, etc. You should report those to the upstream. As a seasoned user, I'm sure you're familiar with the bug report process.

* Many usual things seem to no longer work. For example, C-x o seemed not to work, but apparently it was only while the many packages loaded and compiled. Pressing backspace in file path removes whole components, why not but how do I remove only one character, etc.

This is pretty likely. Given that hardly anyone use non-vi editing style, almost everything is evil-ish. If something is not working with your common emacs-style bindings, it's not very likely to be discovered if no one is using emacs editing style.

This is a big sign that you're not the target user.

But if you want you can report the bugs for any specific broken bindings.

* Following [spacemacs.org/doc/QUICK_START.html](https://www.spacemacs.org/doc/QUICK_START.html) it's not clear what I win here.

Two things here. You'd always better use develop.spacemacs.org/*. The documentation of master branch, as well as master branch Spacemacs itself, is not actively updated. Second, the editing style of the majority of community doesn't fit yours, and your 25 years of Emacs customization is definitely not replaceable by any community-driven configuration, you win nothing here. Why are you expecting anything else?

* vi-style key binding by default in all doc feels outlandish ... for a current emacs user (and probably not only me).

Exactly, I just said above, "When you choose emacs or hybrid editing style you're already not the main target audience. Good luck."

* I feel that I lost the familiar emacs behavior.

Yep.

* It's not clear what I win here.

Nothing.

* When I finally want to "explore the interactive list of carefully-chosen key bindings" with M-m which is apparently what I should understand when the doc says "press space", it doesn't even work.

No, only the key bindings for vim editing style is carefully chosen.

So, I can't even start to taste the promised "sophisticated and polished set-up, focused on ergonomics, mnemonics and consistency."

It's not perfect and has many known issues not fixed. But the major problem is, you're not a target user.

A number of people might have found a nice place with a wonderful emacs setup, but starting from what I believe is a common situation and following instructions only leads to trouble after trouble.

Hope this helps. I may try a third time later, hoping that what is to be won is clearer and the path with less hassle.

As I said, the majority of the community is using evil editing style. Unless you or anyone made contributions to polish the emacs editing style, you're not likely to get anything more than what you've experienced.

lebensterben avatar Jun 14 '21 22:06 lebensterben

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

github-actions[bot] avatar Jun 14 '22 22:06 github-actions[bot]

Thanks again for your comments and explanations.

Given that hardly anyone use non-vi editing style, almost everything is evil-ish. "When you choose emacs or hybrid editing style you're already not the main target audience. Good luck."

From https://develop.spacemacs.org/doc/DOCUMENTATION#who-can-benefit-from-this :

But it is now perfectly usable by non Vim users by choosing the emacs editing style.

The two citations above seem to oppose somewhat. It might be a good time to try again, following your advice.

(Also from same link above:

Emacs users wanting to learn a different way to edit files or wanting to learn Vim key bindings or even wanting to mix both editing styles by setting their style to hybrid.

That could be me.)

For a slightly different perspective, I've been using spacemacs for quite some time, in emacs mode, and the links stopped working for me as well. I can use them with Tab/Shift-Tab and Enter, but clicking still inserts a newline where clicked.

opie4624 avatar Jun 17 '22 18:06 opie4624

I spent some time going through git bisect and discovered that on my platform (ArchLinux, GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6) of 2022-09-12) reverting 21551b6995e38110ce61fec58f608aa180b1d4fc makes mouse clicking url links in the Spacemacs buffer work again.

I will test Monday on my work machine (Mac M1) as well.

opie4624 avatar Dec 31 '22 00:12 opie4624

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

github-actions[bot] avatar Mar 30 '24 12:03 github-actions[bot]

This is pretty stale, I have just tried to click on the links on the home buffer and they seem to work for me.

smile13241324 avatar Mar 30 '24 13:03 smile13241324