Alias automatically deleted when the last ref renamed

Archive Feedback
#1

An alias will be automatically deleted when:

  • 1.The last rem reference that uses the alias is changed to use another alias or default name.

An alias will not be automatically deleted when:

  • 2.The last rem reference that uses the alias is simply deleted. (by using backspace or something)

Question:

  • Is it a bug or an intended feature?
  • If it’s a feature, do you think it’s a good feature?
How to remove an alias?
#2

I prefer an alias won’t be deleted simply because it’s confusing. It took me a while to figure out what conditions an alias will be deleted and honestly still I’m not so confident about the conditions. Additionally, I feel the condition 1 and 2 are inconsistant, making it more confusing.

#3

just explaining the issue in detail

the errors(possibly) occur when the alias is not referenced anywhere, the following behaviour is observed

  • referencing an alias new(created from reference)/old(previously existing) when renamed by adding alias to the reference, actually renames the alias, i-e it can be said that the previous alias gets deleted

this behaviour seems unacceptable in the circumstance that the alias that was deleted might be required while referencing it at another place, meaning to say pressing ‘[[’ and searching for the deleted alias will not show any results.

#4

Apologies for the delay, could you pls confirm if the behaviour has changed or still persisting?

#5

Thank you for replying. It’s still persisting and the conditions in which this behaviour happens seem unchanged.

It’s reported on Github. Hope this helps!
alias-auto-delete

2 Likes
#6

First of all, thank you so much for exploring this in detail.

I see it like this:

  1. I think it can be a good practise to automatically delete aliases if they are not being used anywhere - less cluttering the search?
  2. Also the next time one needs to create an alias that they would be using multiple times, all it takes is to [[ and reference the original rem and then make an alias. I agree it’s an added step, but when you think about it, it takes away the need to manually delete all unwanted alias that one might have created mindlessly while taking notes.
  3. Having said that, I see an inconsistency in that workflow. Deleting an alias using backspace should also then remove the alias from the list, if it was the last reference. Maybe if we could change that, all this would feel more consistent and efficient?
1 Like
#7

I am in favor of this as well. I don’t see a workflow where renaming and deleting would make a difference. Maybe there are ones? (We should ask the original implementor - likely Martin - if this differentiation is intentional or a bug.) Also make sure that deleting the last tag behaves consistently with deleting the last reference.

In any case it seems like you could force the retention of aliases through renaming (and - after bugfix - deletion) if you apply an arbitrary tag to the alias itself.

One likely not intended use case is building some dynamic OR searches where aliases are the subtypes:

image
image411×584 11.2 KB

#8

Yes, I have bumped this up with Martin, to understand the intention here better :slight_smile:

Cool workflow example, I have always wanted such a behaviour to be in-built to the tag hierarchies themselves though.

For example,
If Red and Green both have the tag -“Color”
Then all rems that have been tagged with red should also show up in the Tag backlinks of Colour.
I think this is already possible to some degree, haven’t tested it out thoroughly

#9

Tag inheritance is there in the data model, it is just not enforced/used that much in the frontend yet.
The only example is the tag counter after a rem:
image

#10

Correct! Hoping to see more love shown there in the front-end

#11

Thanks for your thoughts. What you guys are saying completely makes sense. I think it’s worth mentioning about what roles Aliases power-up should play. In my opinion, there are two possible roles it can play:

Role 1: as a name of reference links.

Example case
  • Cat
    • Aliases
      • My favorite animal
  • In another rem
    • [[My favorite animal]] came my home today.

Role 2: as an alias intrinsic to the concept

Example case
  • Cat
    • Aliases
      • Felis catus (scientific name for cat)
  • In anohter rem
    • [[Felis catus]] is a domestic species.

Role 1 is for when you use an alias just to fit in a context. It’s not intrinsic to the concept so it should be okay to delete when the last reference is deleted.

Role 2 is for when you use an alias intrinsic to the concept. You might want this type of aliases not to be deleted.

My thought

If Aliases power-up is used as role 2, I think aliases shouldn’t be automatically deleted since it might cause unintentional deletion. Having said that, in the current implementation Aliases power-up seems more suitable for role 1. If the choice is so, that’s fine but one thing I found unnatural is that the word “Aliases” sounds more like role 2 than role 1, at least to me. It could be “Reference renaming” or something. Sorry, I don’t have a good sense for naming things.
In conclusion, while I’m okay even if aliases gets automatically deleted, I feel some unnaturalness between the wording “Aliases” and its role.

2 Likes
#12

I really love your insight here, very good observation there!

You thoughts align with mine, I have also felt the uncanny feeling of these two roles that you mention. Like you precisely deduced, the automatic deleting of the Alias is beneficial for the Role 1, and definitely not for Role 2.

But practically, we have noticed that most of the times, the usage of Alias is for Role 1, rather than Role 2 (but it may very well be different for others) and at the same time, this auto-deletion doesn’t seem to be doing much harm to role 2, as most of the times at least one reference has been made to the Aliases defined. Worst case we end up having to define it with the Alias next time we wish to use the term.

It seems to us like a small price to pay, while getting the benefits for the larger proportion of use cases. But we are still open for suggestions and ideas, if there was a novel way to cover all edge cases, we would be happy to implement it in the future.

1 Like
#13

Since, this is working as intended, I am moving this into the general discussion category as it contains valuable discussions.